Closed Bug 66248 (AddBookmark) Opened 24 years ago Closed 23 years ago

[RFE] Ability for page javascript to add bookmark

Categories

(Core :: DOM: Core & HTML, enhancement, P5)

enhancement

Tracking

()

VERIFIED WONTFIX
Future

People

(Reporter: rebron, Assigned: jst)

References

Details

Desired effect: allow users to add a url from a web page into their bookmarks file. A web builder would program "Add Page to Bookmarks", just like "the Add Tab to My Sidebar". Is this possible now? If not can we get this in.
*** Bug 66252 has been marked as a duplicate of this bug. ***
*** Bug 66252 has been marked as a duplicate of this bug. ***
Old bugs related to this rfe: - Bug 29770, which asked Moz to match IE's window.external.AddFavorite [invalid] - Bug 38446, which is the same as this rfe. [marked as a dup of 29770]. This bug may depend on bug 47599. (I'd prefer to have a "file bookmark" dialog come up than an "allow this page to add itself to bookmarks?" dialog.)
Severity: normal → enhancement
Summary: [RFE] Ability to Add Bookmark via a Webpage → [RFE] Ability for page javascript to add bookmark
I don't see any more bugs this is likely to be a dup of, so confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Additional Comments From Ben Goodger 2000-11-17 20:50 in Bug 29770: If webpages want to add bookmarks, they can use a signed script to access XPConnect, then get the bookmarks service and call 'AddBookmark' on it. *** This bug has been marked as a duplicate of 29770 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
That's not a reasonable solution. I shouldn't have to give a page full access to my system/account just so the page can make it easier for me to add it to bookmarks.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
There should be no problem with you bookmarking the page on your own. There is no need for the page to interact with the browser's bookmarks. This is a duplicate, please resolve as dupe and reopen the other one.
I've seen a site use print() legitimately. (www.iht.com formats their articles to be readable on the screen, and the "print" links go to pages that try to print themselves onload.) A site that uses script-generated urls might want to do something similar for bookmarking.
printing and bookmarking should require signed access. If your concern is that they can ask for one privelege and abuse another then file another bug about blanket vs specific security permissions. This bug is still a dupe.
Fixing this bug would partially fix bug 71138, "[RFE] Add Bookmark button", by letting users put this bookmarklet on their personal toolbar: javascript:window.external.AddFavorite(location.href,document.title);
Status: REOPENED → ASSIGNED
Target Milestone: --- → Future
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged radar. You can filter out this email by looking for "ironstomachaussie"
Priority: -- → P5
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
Moving to javascript component to get some attention there. Having this in bookmarks maybe the wrong place.
Component: Bookmarks → JavaScript Engine
you need to reassign to get anything done. and JSEng is guaranteed to be the wrong component. Personally, I'm still opposed. In case I didn't make myself clear, I don't believe .print() is legitimate either. I want to be able to read a printer friendly page, because such pages are also reader friendly. I've seen pages which call .print and the close. This bug is still a dupe and all conversation really belonds in the original bug. mstoltz: is there a timeframe for limited script permissions? All/nothing granularity really sucks. Even microsoft's awful tainting form might be useful. Something like: grant permission to use class Foo and prohibit that class from calling any other classes that aren't normally callable.
Component: JavaScript Engine → DOM Mozilla Extensions
.
Assignee: ben → jst
QA Contact: claudius → lchiang
I agree with timeless. There's absolutely no point in that feature other than to get the user to do something he didn't want (or wouldn't have done himself). Bookmarks|Add Bookmark is easily accessible and obvious. Any user who wants to bookmark the page can do so easily. If he doesn't want to, there's no point in asking him. Recommending WONTFIX. (It's offtopic, but I don't know the bug#, so: I once had a use for print in an intranet app. But there, some limited permission for that app (domain) only would have done the job. For the rest, no access to print() - printer-friendly pages often look as the whole web should look like IMO.)
I agree with BenB and timeless, IE's add-favorite-from-javascript command is usually used to try to get the user to add an unwanted bookmark. Web authors shouldn't feel compelled to clutter their pages with "Add bookmark" buttons, because browsers have the feature built in.
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → WONTFIX
*** Bug 162059 has been marked as a duplicate of this bug. ***
verified wontfix.
ops
Status: RESOLVED → VERIFIED
Alias: AddBookmark
QA Contact: lchiang → ian
*** Bug 214530 has been marked as a duplicate of this bug. ***
Continued in bug 214530...
*** Bug 214530 has been marked as a duplicate of this bug. ***
Following various discussion on #mozilla. Why this should, in fact, be implemented: Firstly, about how it should be done. When clicking on a link, dialog boxes asking/confirming something are a fairly integral part of web browsing. Clicking a 'bookmark' link should bring up a standard dialog box asking whether the user would like to add the url to the bookmarks. The URL should also be displayed. The web page should be able to set the title for the bookmark, which should be editable by the user (as per IE). Why: Sometimes a web site may not, for whatever reason, want the user to bookmark that particular page, but bookmark a different page (usually an entrance page). Additionally, for example the user may be in another sites frameset (hotmail is a particularly ugly example), and so definitely not want to bookmark that site (with a hotmail link for example, the page would not even load up as the session would have expired). Why this is not 'obnoxious': The user clicks on a link, and is presented with a standard dialog box which cannot be hijacked maliciously by a web site. Receiving a response from clicking a link is fairly standard behaviour :) Pleasing the 'I hate popups' crowd: In the preferences/Advanced/Scripts and Plugins, an entry entitled something like "Allow a link to open up a bookmark dialog" would enable this to be turned off while maintaining all previous functionality. Why dragging a link to the bookmark bar isn't enough: Dragging a link to the title bar has several problems. A simple one is that the user may click on the link instead, and navigate away from the page, which they do not want to do. Secondly, the text of the bookmark appears to take its name from the <TITLE> tag of the destination web page. Apart from questions about how this would work in an offline environment, there is debate over whether the behaviour should be as such or whether it should take the text from the TITLE tag of the link itself. Having a bookmark facility like javascript:window.external.AddFavorite(location.href,document.title); means that this ambiguity is resolved. I hope this will be taken into consideration. Ian
i'll note that i was sleeping, it happens, i'm sorry, i shouldn't let it happen, ever. anyway, we chewed ian out a bit later on irc. for posterity: > When clicking on a link, dialog boxes > asking/confirming something are a fairly integral part of web browsing. No. They aren't. Any dialogs you get from clicking on links are bugs. In fact in many cases they're significant security issues. (Jesse: remind me to suggest a solution for xpi.) There is only one set of dialogs I know of that people are used to seeing when they click links, and anyone who sees them more than once is named timeless, because everyone turns them off (they're security transition dialogs, they're annoying and useless, don't ask me why I don't turn them off). > Sometimes a web site may not, for whatever reason, want the user to bookmark > that particular page that's not the web site's business. we're a user agent. if the web site wants to control bookmarking it should use flash or pdf. > but bookmark a different page (usually an entrance page). right, so microsoft would want to prevent me from ever bookmarking useless content and instead offer me a bookmark to http://www.msn.com/, thanks. no. > Additionally, for example the user may be in another sites frameset > and so definitely not want to bookmark that site (with a hotmail link for > example, the page would not even load up as the session would have expired). So why shouldn't the site simply have a link which the user could *choose* to bookmark? what if I want to use some other kind of bookmarks, e.g. i drag links to a file system (.url or something)? why should sites be able to create links which I can't use the way I want to? > In the preferences/Advanced/Scripts and Plugins, an entry entitled something > like "Allow a link to open up a bookmark dialog" would enable this to be > turned off while maintaining all previous functionality. *cough*. that thing is already way too complicated and confusing and useless because of the poor decissions of previous designers. > A simple one is that the user may click on the link instead, > and navigate away from the page, which they do not want to do. um, how do you know it isn't what the user wants to do? > there is debate over whether the behaviour should be as such or whether it > should take the text from the TITLE tag of the link itself. so this is a major reason for adding some other feature? I can offer a simple solution for this last problem which is to prefill the description field with the other value. if the user then wants to use it, the user can easily do so.
See also bug 305398, "JavaScript sidebar.addpanel should have similar behaviour as adding bookmark manually."
How about adding this bug disabling it with the 'disable common annoyances' tickbox?
How arrogant marking this as wontfix. Most users who click a bookmark link would expect it to appear as a proper bookmark not appear in the sidebar. If the website designer wants to present a one click (2 click including confirmation) bookmark. who here has the right to say no? Why do a half ass attempt and add it to the side bar, either ignore attempts to add bookmarks altogether or do it properly. Its hypocritical that you'll allow webmasters (google) to steal bandwidth by preloading websites which generate annoying popups if you have 'approve cookies' enabled, and yet get all high and mighty about bookmarks.
or at least put the 'open in sidebar' choice on the add bookmark dialogue so the user can make an "Informed Choice"
Can someone explain to me why it's possible to add bookmarks that open in the sidebar, but not ones that open in the main window? The UI seems to be identical, except for that **** checkbox.
in my naivety i am surprised that you can not bookmark a page using mozilla. i sell stuff and would like to offer a bookmark on the replacement parts page - so that people do not have to trawl the internet again to find that small part they need. i really would like to try and keep the customers coming back. surely its about making it easier for users to have a better surfing experience? it does seem a rather odd omission and i would love to see a fix for this 'bug'. thanks for reading.
I realize that this is marked "VERIFIED WONTFIX", but I have to voice agreement with the other recent comments (since the beginning of 2007. Sure, an aggressive or malicious site could trick the user into creating a bookmark, but that's not a significantly greater security risk than tricking the user into clicking a link. And it is certainly inconsistent with the ability to create a sidebar item. I'm new to the Mozilla project, but looks to me like the person or people in the Mozilla community, who decides what can happen with the sidebar, disagree with the person or people in the Mozilla community who decides what can happen with bookmarks.
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.