User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 The dialog that pops up when you bookmark a page prematurely says that the page has been bookmarked. Reproducible: Always Steps to Reproduce: 1. Cmd-D to bookmark the current page (Probably works the same on other platforms with Ctrl-D) 2. Read the dialog box that says "Page Bookmarked" Expected Results: Expected it to only tell me a page has been bookmarked only after actually adding it to bookmarks.

Agree. It should be changed to "Bookmark Page" or something similar.

Just another comment. Even if you do not hit Done, and just click outside of the box, it still bookmarks the website. The box is just confirmation that the site has been bookmarked, though the wording should be better. Most users will assume the site will not be bookmarked until "Done" is clicked, while clicking any where outside the box will confirm bookmarking.

You're right, it does. The behavior of the bookmark dialog seems counter-intuitive this way, but the text is right.

Maybe the Text on the current "Done" button should changed to "OK", to more clearly show that it is confirmation. Most users will think that the site is not book marked until they hit "Done", but with "OK", they will see it is confirmation.

This changes the text from "Done" to "OK". Can it get a review?

This is the entire browser.dtd file, the relevant part is at "<!ENTITY editBookmark.done.label "OK"> "

I also feel that the dialog should be a modal dialog right?

How so?

Comment on attachment 332078 [details] [diff] [review] Patch Wrong format.

@Tyler, Currently it looks like a simple HTML DIV. Hence for a busy surfer, he might just open the dialog but he might click on somewhere and totally forgot this URL.

Please read comment #2

I agree it is misleading, seems like the URL is already bookmarked but isn't. It is true that if you already have it bookmarked then the headline says Edit Bookmark, good, but "Page Bookmarked" is still illogical until the deed is actually done.

My version of Firefox (3.0.1) displays the described dialog but does NOT appear to bookmark the site. IMO, this is the desired behaviour and the title of the Dialog should be changed. (People need to choose a folder for the bookmark, after all). Note: This is actually a bug, not an enhancement request. Probably a "minor" bug rather than a "trivial" one. It's potentially confusing to users, and that's more significant than a cosmetic problem like a typo. (I originally came here after hunting through my bookmarks for the not-actually-bookmarked page).

Keith, you seem to be having a different problem. Use a new bug to report it.

I will be working on trying to get something that makes more sense up soon.

I AM talking about the same bug - just not very clearly. :) There are basically two options: (1) Bookmark the page immediately, leave the dialog title as "Page Bookmarked" and maybe change the "Done" button to "OK". (2) Don't bookmark the page until the Done/OK button is clicked and change the dialog title to something like "Add Bookmark". I was casting my vote for #2. It is the standard for confirmation dialogs to confirm, not tell you about something that's already happened. Though the current approach is occasionally useful, it violates user expectations. I was also arguing for the upgrade of this job to a bug rather than an enhancement request. IMO, non-standard interface behaviour is a bug. Thanks.

@Keith Bissett - NOW I understand this novel Ctrl-D behavior, and like that it commits first, asks questions later, and is more easily dismissible. I agree that the change in behavior is a minor user familiarization speedbump, but it's not a bug. The commit-first behavior is made necessary by improving the pointing-device interface, making the dialog less modal. (See Thoughts at the end). So I vote for your (1), but instead would relabel "Cancel" to "Remove" in the dialog. Versions: Firefox 3.5x, 3.6 Win32 PROBLEM: The Add and Remove dialogs are inconsistent. When adding, the "Cancel" button is mislabeled - it's inconsistent with the "Page Bookmarked" committal. EXPLANATION: When adding a bookmark, the "Cancel" label is functionally incorrect, because the bookmark has *already been committed* by Ctrl-D. "Remove" is a better label in this dialog because it reinforces the concept that the bookmark has *already been saved*, but is open for optional editing. When removing a bookmark (Ctrl-D in a page which is bookmarked), there's an extra, out-of-place "Remove Bookmark" button at the top of the dialog. This is in a nonstandard place and is redundant, because the "Cancel" button should be labeled "Remove". SUGGESTED SOLUTION: Replace "Cancel" with "Remove" in both the Add and Remove dialogs. Remove the redundant "Remove Bookmark" button in the Remove dialog. ADVANTAGE: Introduces and reinforces the notion that Bookmarks are saved immediately, and can be removed with a Remove button in a consistent location. No Cancel function is required. =============== UI DESIGN THOUGHTS leading to the above assessment: - Modal dialog boxes (which block usage of the rest of the app until the dialog is satisfied or dismissed) have always sucked, especially for pointing device users. - Don't punish one class of users: don't force touchpad & mouse users (especially with large screens) to either hunt down one of two dialog buttons or take a hand off the pointing device to hit Enter. That's too much work simply to confirm a mere (let's face it, inconsequential) bookmark. - Reducing dialog box modality by making them click-away dismissible is a good thing, and doesn't hurt keyboard users (enter and escape both still work). - Making the Ctrl-D dialog more easily dismissible mandates that it "do the right thing" by default, meaning always commit first, because that's what the user wanted in the first place. - The addressbar star saves (to Unsorted Bookmarks) with no dialog at all. So now Ctrl-D is really an expansion of the star, with correct default behavior (commit to the last selected folder) and an easily dismissible dialog. - Mainly, old-school Ctrl-D users face no increased complexity beyond UI wording changes. If one doesn't look at the screen (Ctrl-D, Enter), one would never notice the change. So, don't look(hee). YES, this inverts the dialog/action paradigm to "action followed by dialog." But I would argue that bookmarks have suffered from the wrong UI design since their inception. - They should never have been highly modal (must-click-OK-to-save-the-bookmark) in the first place. Hand off mouse, or hunt the button. Ridiculous. In the 90's, saving was expensive, as hard disks were slow, but now it's basically free. In the 90's, screens were small, and mice didn't have to go far to find the dialog buttons. Times have changed. - Bookmarks are simple creatures. They don't require complicated forms or validation, and have no appreciable system risk (as opposed to TCP/IP settings or user account configuration). There's just no justification for a strongly modal dialog box. - Some actions are modeless: ctrl-+. Some are highly modal: Save Page As. I think bookmarks are a unique enough database+UI object to merit a moderately novel, yet transparently backwards-compatible, UI approach. So in my view, this behavioral change has been a long time coming, and is well justified. It just makes life easier for pointing-device users, without penalizing keyboard or accessibility users. Unless I missed your point. Oh, dear.

I can't reproduce it with latest Nightly. If you still can reproduce it, please reopen this bug.

I'm still able to reproduce this issue with Firefox 38.0.

Edit: To avoid confusion I'm pointing to the enhancements suggested in the discussion.

No problem here. The page is bookmarked in "Bookmarks Menu" folder with "Ctrl+D" keyboard shortcut, even if I don't click "Done" and click the page again to hide the notification about bookmarking. Can you reproduce it with fresh new clean Firefox profile?

I have made an extra post (comment #21) to avoid the confusion which you now stepped into :) The discussion has lead that there is no bug but that things could be enhanced to reduce confusion. This is also why the ticket was changed into an enhancement in comment #4.