Currently, the Add Bookmark dialog (CTRL+D) says "Page bookmarked" in its title regardless of whether the page already *has* been bookmarked through clicking the Star, or whether it is going to be bookmarked if the user presses the "Done" button, for example because the dialog has been invoked directly via CTRL+D, without clicking the Star first. The dialog title should reflect the actual condition. For this, I suggest to use the entity "bookmarkPageCmd2.label", which accessibility used for the panel's title prior to fix for bug 415105. It says "Bookmark this page", and should be used when CTRL+D is being pressed on a page that has not been bookmarked yet. The dialog already knows about the bookmark not being filed yet: The Undo button is unavailable. So within the same logic, the title should be set correctly to reflect the actual state: The user is *going to* bookmark the page, it hasn't been bookmarked yet.

Are you sure the bookmark hasn't been added by the time the dialog is displayed? If that's so (which would be the only sane sequence of events), why does it sometimes take several seconds to display this dialog if not because the bookmark is being added? They only other explanation I have is that the code is searching the DB to see if this page isn't in the DB. In this case, the speed of this should be improved a LOT. The DB FF is using is relatively tiny, so it shouldn't take seconds to see if the address is in DB.

And if something is going to take some time, a mechanism should be in place to prevent what I described in the 2nd paragraph of the comment 108 in bug 393509 (in the worst case, a visual indicator asking the user to wait and not press Ctrl+D again).

Blocking future milestone, but not beta 3.

Bug 393509 comment #108 shows how too terse a UI may lead to misunderstanding: here is how I interpret the events described there: - Case #1: The page was bookmarked and the browser said so, so the user hit Esc, believing it would "do nothing" (and keep the bookmark) but actually it "cancelled" (the bookmark addition). - Case #2: The user unwittingly hit Ctrl-D twice. The first time, the bookmark was added, but the user wasn' conscious of it, so he hit Ctrl-D again, thinking that his first keypress hadn't reached the browser. Then he was offered to edit or remove a bookmark which he wasn't aware of having added: so he blames Mozilla for not having made it obvious that his first keypress was received... Maybe instead of "Page bookmarked" the label (for a first Ctrl-D or a click of the unbright star) should be "Page being bookmarked" to make it obvious that Esc would cancel the bookmark (while Enter would leave it in)? (Note: I don't care whether the actual addition happens when opening or closing the dialog or whatever replaces it, as long as the result of user actions is unambiguous even for people from different origins, running on different OSes, knowing different non-Mozilla browsers if any, seeing this interface for the first time, and unaware of the discussions at b.m.o. A tall order, I know; but I believe it is solvable.)

We're string frozen, are we still intending to take this?

(In reply to comment #5) > We're string frozen, are we still intending to take this? We can just use the existing dialogTitleAddBookmark from /browser/locales/en-US/chrome/browser/places/bookmarkProperties.properties

Where is that string currently used? Or what was it used for, if it isn't anymore. Reusing existing strings is not generally secure, the context needs to be at least *very* similar.

It was added by bug 357316 in March 2007, for use in the Fx2-style add bookmark dialog, which used it for everything until August, when the panel took over for everything except the context-menu "Add a Keyword for this Search" item, which still uses the dialog, and that string, to add a bookmark and keyword. The panel and dialog both size to content, so the only risk would be an extremely cunning locale, that discovered the string was only currently used for adding search keyword bookmarks, and made an unfortunate decision to mention keywords in the title. That strikes me as really really unlikely.

Alex and I thought about this and walked through some use cases, and determined that the right way to fix this is actually in bug 415781: - keep the title of the panel "Page Bookmarked" - change the title of the panel to "Edit This Bookmark" in the case where the page is already bookmarked, and calling the dialog will edit it That way ESC always acts as the "undo" option for the action described by the panel title.

That might still be confusing because the normal behavior, at least on Windows, is for the Cancel button to prevent an operation from proceeding, not undo "permanent" changes.

To add to my comment #10: if something comes up (literally -- another window, which happens often in a multitasking environment), the bookmark dialog disappears, and the user is left either with an undesirable button or undesirable attributes of that bookmark. This problem is cause by the overall design of the window. It should be a regular modal dialog.

Correction: undesirable button => undesirable bookmark

Setting to invalid based on beltzner's comments in comment #9. Beltzner: please reopen if you disagree.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv