Closed
Bug 230349
Opened 21 years ago
Closed 21 years ago
Adding multiple history entries to bookmarks fails and context menu reads "Bookmark this Page(L)"
Categories
(Core Graveyard :: History: Global, defect)
Core Graveyard
History: Global
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: durbacher, Assigned: durbacher)
Details
Attachments
(1 file, 4 obsolete files)
4.11 KB,
patch
|
neil
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031209
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031209
As summary says...
Reproducible: Always
Steps to Reproduce:
1. Open bookmarks window (e.g. Ctrl-H)
2. Select two or more history entries (but no 'folder'!)
3. Right-click
4. Read label of context menu
Actual Results:
"Bookmark this Page(L)"
Expected Results:
"Add Links to Bookmarks" (or similar)
The label is taken from
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/locale/en-US/contentAreaCommands.dtd#18
which earlier said "Add to Bookmarks", but was changed:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpfe/communicator/resources/locale/en-US&command=DIFF_FRAMESET&file=contentAreaCommands.dtd&rev2=1.15&rev1=1.14
probably without this usage in mind...
Shortcut letter is "L" which makes it look even more strange... therefore I
suggested something with "Link" in it.
This should probably go into history's own files (I cannot think of any other
place where you can bookmark two URLs at once...).
Assignee | ||
Comment 1•21 years ago
|
||
This is my proposal how to fix this bug:
Put a new label/accesskey for bookmarking more than one selected history
entries into the file historyTreeOverlay.dtd. That file only contains tree
labels until now, but I guess it's the best place for the new label because it
is used in historyTreeOverlay.xul. And only there because only in history there
can be several URLs bookmarked at once.
The other possibility would have been to put it where it's "brother" entry for
bookmarking _single_ history entries is:
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/locale/en-US/contentAreaCommands.dtd#53
If this is considered better, I would change the patch to do so. This would
allow for other users of that string if there ever are some...
This patch also fixed the accesskey: previously only the label was changed, the
accesskey remained the same: "L" (this is why there is a "L" in brackets after
the context menu entry).
With my patch it is still "L", but now there is an "L" in the entry so it looks
normal. So it is now switched from "L" to "L" all the time. This is obviously
not necessary at the moment but allows for changes in the future without
glitches as seen in this bug.
Assignee | ||
Updated•21 years ago
|
Assignee: nobody → durbacher
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•21 years ago
|
||
Comment on attachment 138658 [details] [diff] [review]
proposed patch
Requesting r= from Neil and sr= from alecf.
If you test this and encounter problems in the context menu it's probably
covered by my patch in bug 133590 or bug 131182 or several other ones (there
are lots of problems there...), so this patch is really most probably not the
culprit.
Don't be reluctant to say it if you'd like me to change my patch in some way.
Attachment #138658 -
Flags: superreview?(alecf)
Attachment #138658 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 3•21 years ago
|
||
Comment on attachment 138658 [details] [diff] [review]
proposed patch
sr=alecf
Attachment #138658 -
Flags: superreview?(alecf) → superreview+
Comment 4•21 years ago
|
||
Comment on attachment 138658 [details] [diff] [review]
proposed patch
Unfortunately adding multiple bookmarks doesn't actually work :-/
Assignee | ||
Comment 5•21 years ago
|
||
Right, but with this patch it looks nicer... ;-)
(Did I mention that I also don't think I will ever use that feature?)
Assignee | ||
Comment 6•21 years ago
|
||
Adding multiple bookmarks fails in
http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/resources/bookmarks.js#1565
because BMSVC is not defined.
The containing function addBookmark is called from history.js with
aShowDialog=false so the bookmarks are added directly.
When only adding one bookmark, aShowDialog is true and that dialog manages the
adding, so this error does not occur.
pch said on IRC that initServices() and initBMService() have to be used to init
BMSVC properly. Neil mentioned that this might be overkill, but adding a single
bookmark also does this before the "Add Bookmark" dialog appears.
The solutions I currently see are:
1) use the "add Bookmark" dialog also for multiple bookmarks. Easiest solution,
but hell for sombody who adds more than a dozen bookmarks at once.
2) init Bookmark Service with initServices() and initBMService()
3) try to find a smaller set of instructions to init BMSVC
Extending bug summary.
Summary: History context menu reads "Bookmark this Page(L)" when multiple entries selected → Adding multiple history entries to bookmarks fails and context menu reads "Bookmark this Page(L)"
Assignee | ||
Updated•21 years ago
|
Severity: trivial → normal
Assignee | ||
Comment 7•21 years ago
|
||
Calling addBookmark with "undefined" as charset makes the called function use
the charset of the currently open document:
var fw = document.commandDispatcher.focusedWindow;
aCharset = fw.document.characterSet;
(http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/resources/bookmarks.js#1553)
- does this make any sense???
Wouldn't it make more sense to use a "mostly" working charset instead of one
chosen by random?
But I'm not sure what the charset of a bookmark is for, so this might all be
nonsense...
Assignee | ||
Comment 8•21 years ago
|
||
Comment on attachment 138658 [details] [diff] [review]
proposed patch
First patch is obsolete. New patch(es) coming...
Attachment #138658 -
Attachment is obsolete: true
Attachment #138658 -
Flags: review?(neil.parkwaycc.co.uk)
Assignee | ||
Comment 9•21 years ago
|
||
v2 A: do the same as the first patch plus init the Bookmarks Service
Assignee | ||
Comment 10•21 years ago
|
||
v2 A: do the same as the last one plus several other changes:
- as mentioned in comment #7, the charset of the currently open document -
which happens to be "UTF-8" for the history window - is used for the added
bookmarks.
(Don't know about the sidebar case, but it certainly doesn't produce a better
result)
So I guess using that charset UTF-8 directly cannot hurt. I'm not sure of any
possible problems when a bookmark has a wrong charset attached, but IF there
are any, they already existed for"ever".
http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/src/nsBookmarksService.cpp#3226
is where that charset is finally being used, just in case anybody wants to have
a look.
- don't call the bookmarks.js init functions because they init a lot of stuff
we don't need. Instead only init BMSVC and do the adding call to it directly.
- when only one entry is selected to be added, now bookmarks.js cannot do
anything for us, all it does is calling openDialog, so we can do this
ourselves.
Assignee | ||
Comment 11•21 years ago
|
||
Comment on attachment 138753 [details] [diff] [review]
Patch v2 B: do the same as the first one plus do several other things...
Requesting Neil's opinion on the two possible patches.
Please say what looks better to you. Combinations of these patches are also
possible.
E.g. I might leave alone the "one bookmark" case (maybe changing to UTF-8) but
use the "multiple bookmarks" solution from the second patch. Or...
Attachment #138753 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 12•21 years ago
|
||
I think I'd like pch to comment on the use of BookmarkUtils.addBookmark
(especially given the comment about aShowDialog) and also the charset issue.
Assignee | ||
Comment 13•21 years ago
|
||
As a note: firebird also uses "undefined" for charset:
http://lxr.mozilla.org/mozilla/source/browser/components/history/content/history.js#230
But pch probably knows best what to do, so...
Comment 14•21 years ago
|
||
Sorry for the delay.
- about the aShowDialog flag: addBookmarkImmediately is obsolete, because the
modifications to the bookmarks datasource are not processed through the
transaction manager.
- the behavior of createBookmarks when the charset is obviously bogus, it was
written for the case in which the page is bookmarked from the browser window,
not from another window a sidebar panel.
However, we need to infer a charset... We may look at the cache (if it has this
info) but I don't know what to do (except relying on the automatic charset
detection) by not asserting the charset in the bookmarks datasource. Another
solution comes to my mind.
Do we really need the ability to add a bookmark from the history???
I think that loading the page then bookmarking it is a good workaround, in the
improbable case that the user hasn't already done that.
Comment 15•21 years ago
|
||
s/don't know what to do/don't know what to do when cache of the page is expired
Comment 16•21 years ago
|
||
OK, so two more questions...
1. Does Bookmarks/Bookmark This Page add a bookmark immediately correctly?
2. What charset does Bookmark Manager's File/New/Bookmark use?
Comment 17•21 years ago
|
||
1) adding a bookmark via Bookmarks > Bookmarks This Page go through
BookmarksUtils.addBookmarkForBrowser that picks the charset of the doc shell but
it's not correctly handled by the transaction manager.
2) adding a new bookmark exhibits the same pb that when adding a bookmark from
the history. The null or "" charset is sent to BookmarksUtils.createBookmark
that wrongly changes it to the add bookmark window one that turns out to be
"UTF-8" for chrome windows.
We should remove...
if (!aCharSet) {
var fw = document.commandDispatcher.focusedWindow;
if (fw)
aCharSet = fw.document.characterSet;
}
... that is really bogus and check copy/paste and drag and drop (see bug 174197,
that relies on the snipet) operations.
Comment 18•21 years ago
|
||
Comment on attachment 138753 [details] [diff] [review]
Patch v2 B: do the same as the first one plus do several other things...
I think I would stick to using initBMService and addBookmark for now, but with
a third parameter of null rather than undefined as I think that any implicit or
explicit UTF-8 charset would be wrong. I also don't see why you need both init
calls, and definitely not inside the loop!
Attachment #138753 -
Flags: review?(neil.parkwaycc.co.uk) → review-
Assignee | ||
Comment 19•21 years ago
|
||
Both init calls are necessary because the first one inits some variables used
by the second (namely e.g. RDF). And the second inits the service.
Attachment #138752 -
Attachment is obsolete: true
Attachment #138753 -
Attachment is obsolete: true
Assignee | ||
Comment 20•21 years ago
|
||
Comment on attachment 139381 [details] [diff] [review]
revised patch
Requesting r= from Neil.
Attachment #139381 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 21•21 years ago
|
||
Comment on attachment 139381 [details] [diff] [review]
revised patch
>- BookmarksUtils.addBookmark(url, title, undefined, true);
>+ BookmarksUtils.addBookmark(url, title, null, true);
You need to do this for the multiple bookmark case too.
>+ initServices();
>+ initBMService();
Might be worth wrapping this in an if (!BMSVC)
Attachment #139381 -
Flags: review?(neil.parkwaycc.co.uk) → review-
Assignee | ||
Comment 22•21 years ago
|
||
Changes those two things. BMSVC is only _not_ null if you already have
bookmarked several history items during the lifetime of the currently open
history window. No matter what other bookmarks activities are going on. But
yes, it's probably still worth it.
Assignee | ||
Updated•21 years ago
|
Attachment #139381 -
Attachment is obsolete: true
Assignee | ||
Comment 23•21 years ago
|
||
Comment on attachment 139419 [details] [diff] [review]
again revised
Requesting r= from Neil.
Attachment #139419 -
Flags: review?(neil.parkwaycc.co.uk)
Updated•21 years ago
|
Attachment #139419 -
Flags: review?(neil.parkwaycc.co.uk) → review+
Assignee | ||
Comment 24•21 years ago
|
||
Comment on attachment 139419 [details] [diff] [review]
again revised
Requesting sr= from alecf.
Attachment #139419 -
Flags: superreview?(alecf)
Comment 25•21 years ago
|
||
Comment on attachment 139419 [details] [diff] [review]
again revised
sr=alecf
Attachment #139419 -
Flags: superreview?(alecf) → superreview+
Comment 26•21 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•