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)
Core
DOM: Core & HTML
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.
Comment 3•24 years ago
|
||
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.)
Updated•24 years ago
|
Severity: normal → enhancement
Summary: [RFE] Ability to Add Bookmark via a Webpage → [RFE] Ability for page javascript to add bookmark
Comment 4•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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);
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: --- → Future
Comment 11•23 years ago
|
||
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
Comment 12•23 years ago
|
||
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
Reporter | ||
Comment 14•23 years ago
|
||
Moving to javascript component to get some attention there. Having this in
bookmarks maybe the wrong place.
Component: Bookmarks → JavaScript Engine
Comment 15•23 years ago
|
||
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
Comment 17•23 years ago
|
||
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.)
Comment 18•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → WONTFIX
Comment 19•22 years ago
|
||
*** Bug 162059 has been marked as a duplicate of this bug. ***
Comment 20•22 years ago
|
||
verified wontfix.
Comment 22•21 years ago
|
||
*** Bug 214530 has been marked as a duplicate of this bug. ***
Comment 23•21 years ago
|
||
Continued in bug 214530...
Comment 24•21 years ago
|
||
*** Bug 214530 has been marked as a duplicate of this bug. ***
Comment 25•21 years ago
|
||
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
Comment 26•21 years ago
|
||
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.
Comment 27•19 years ago
|
||
See also bug 305398, "JavaScript sidebar.addpanel should have similar behaviour
as adding bookmark manually."
Comment 28•19 years ago
|
||
How about adding this bug disabling it with the 'disable common annoyances' tickbox?
Comment 29•18 years ago
|
||
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.
Comment 30•18 years ago
|
||
or at least put the 'open in sidebar' choice on the add bookmark dialogue so the user can make an "Informed Choice"
Comment 31•17 years ago
|
||
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.
Comment 32•16 years ago
|
||
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.
Comment 33•15 years ago
|
||
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.
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•