Closed Bug 396513 Opened 17 years ago Closed 17 years ago

esc key does not cancel the 'bookmark this page' action (starring popup)

Categories

(Firefox :: Bookmarks & History, defect, P5)

defect

Tracking

()

RESOLVED WONTFIX
Firefox 3 beta3

People

(Reporter: phiw2, Unassigned)

References

Details

(Keywords: polish)

STR
1. command+D or click on that star icon
2. page is filed as bookmark and a dialogue pops up
pressing the esc key closes the dialogue box, but doesn't cancel the action

actual result: page is bookmarked
expected result: no bookmark added / no action taken

step 2 above is already poor ui - the page shouldn't be bookmarked unless the user clicks OK. Probably worth its own bug if it doesn't exist yet.
Flags: blocking-firefox3?
OS: Mac OS X → All
Hardware: Macintosh → All
Severity: major → normal
Summary: esc key does not cancel the 'bookmark this page' action → esc key does not cancel the 'bookmark this page' action (starring popup)
Flags: blocking-firefox3? → blocking-firefox3+
Keywords: polish
Target Milestone: --- → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: -- → P5
This is a tradeoff we're making consciously, so we're going to leave it as is in the absence of further data.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: blocking-firefox3+ → blocking-firefox3-
Resolution: --- → WONTFIX
This isn't a bug. Once you his control or command-d (or the star) the page is saved. The choice at that point is to leave it there, edit its location, or to delete it. It's already saved though. This is part of the new Places design.
(In reply to comment #1)
> This is a tradeoff we're making consciously, so we're going to leave it as is
> in the absence of further data.
> 
Maybe the preference browser.preferences.instantApply (or something) should be relevant? (If the pref is false, which is not the default, Esc might be expected to cancel the action?)
Target Milestone: Firefox 3 Mx → Firefox 3 M11
(In reply to comment #1)
> This is a tradeoff we're making consciously, so we're going to leave it as is
> in the absence of further data.
> 

:-(

If someone accidentally hits the wrong keyboard shortcut, or accidentally slips with the mouse and hits that star thing, there is no escape ?
That is all very foreign to how my OS (OS X) works.
There is an escape. It is the button labeled, "Delete".
(In reply to comment #1)
> we're going to leave it as is in the absence of further data.

Here's more data: the design is absurd. First, you removed the text zoom feature, and now Esc doesn't cancel the operation. It is widely expected to get a chance to escape/cancel an operation with an Esc key. This is pitiful. 

What kind of data are you waiting for?
(In reply to comment #5)
> There is an escape. It is the button labeled, "Delete".

So, to cancel the adding, one adds the bookmark and then deletes it? This seems more logical to you than just canceling the operation? Nobody starts to add a bookmark to do some deleting. They do it to add one or do it by mistake, and it's much more logical to press Esc than click the Delete button to cancel  the operation because the assumption (to experienced users, anyway) is that the bookmark hasn't been added yet (the open dialog is the indicator of that). Why redefine how UI works... in a bad way?
No intention to spam this issue, but let me just add that i fully agree with comment #8. The current behaviour is illogical and absurd.
Wouldn't ctrl+z be more appropriate than esc?
>> Wouldn't ctrl+z be more appropriate than esc?

IMHO it would be an alternative. Still it could not substitute esc.


Generally speaking since ever i have been using home-computers (1994) esc expresses the users wish to leave the dialog and return to an unmodified previous state. I doubt one would find a successfull product for PC-users from the past, where the esc key was equal to the enter key.
This Bug should be re-opened and its scope expanded, and here's why:

As (I think) Tony alluded to in Comment #3, Ctrl+D'ing and changes to the starred-bookmark are now INSTANTLY-applied (ie: no "OK" click required), which means that if focus is lost from the 'Bookmark This Page' dialog (the nameless dialog that appears upon Ctrl+D'ing or clicking a yellow Star - I'll refer to it from herein as the 'BTP dialog'), the change is made anyway. This is absolutely not acceptable unless I have browser.preferences.instantApply set to 'true', which contrary to what Tony said is NOT the default. Regardless, one way focus can be lost is by pressing Esc. However, there are other ways focus can be lost, and this is a problem.

Try this:
1. On a currently-Unfiled page(white star), click the star in the Location Bar --> it turns yellow and the bookmark is immediately and automatically placed in the BTP dialog's 'Unfiled Bookmarks' folder. You can confirm this if you open the Library to that folder. (Note: Ctrl+D'ing immediately places the item into the 'Bookmarks Menu' folder instead)
2. Click the now-yellow Star --> the BTP dialog pops up; --> the 'Unfiled Bookmarks' folder is already selected as that's where it is currently located, so to be honest even if pressing 'Esc' key exited the dialog, it isn't going to change anything at this point.
3. Click the 'Folder' dropdown and select 'Bookmarks Toolbar'; notice that the bookmark *instantly* is moved to the BT.
4. Hit 'Esc' key; dialog closes; notice the bookmark remains on the Bookmarks Toolbar despite the fact that the Esc key's purpose is to BACK-OUT of changes. [from Wikipedia: "the escape key was appropriated by application programmers, most often to mean Stop. This use continues today in Microsoft Windows's use of escape as a shortcut in dialog boxes for No, Quit, Exit, Cancel, or Abort."]
5. Click the yellow Star again; notice that the pre-selected Folder in the BTP dialog is now (correctly) 'Bookmarks Toolbar'.

With the BTP dialog still open, select a different Folder (such as 'Bookmarks Menu'). Now try these other losses-of-focus tests:

6. Click back in the page
- BTP closes, item is moved, despite me never confirming the move.

7. Scroll the mouse-wheel outside the BTP dialog
- BTP closes, item is moved, again despite me never confirming the move.

8. Alt+Tab
- In Windows at least, the OS's application-switching pop-up appears. Alt+Tab back to Minefield. Notice the BTP dialog is now closed and the bookmark has been moved.

9. Other app stealing focus
- the most basic example I could think for testing purposes was to try deleting the Minefield application folder while the application was open, knowing that is would throw an OS "Error deleting file or folder" alert as the files are in use. So what I did was switch to File Explorer, click 'delete' on the folder, then quickly switch back to Minefield and hit my yellow star. BTP dialog appears, I clicked & changed the Folder, then waited for the OS alert. Sure enough the alert appeared, focus was lost, the BTP dialog disappeared and my bookmark was moved.

--
A Firefox 3 user, having never been exposed to this new behaviour (and no doubt not being told about the change) may therefore inadvertently find themselves with a shitload of unwanted bookmarks.

I propose what is needed is:
- removal of this new 'instant apply' behaviour;
- a 'Cancel' button in the BTP dialog and associated Esc-key behaviour
- persistence of the BTP dialog after focus-loss

I therefore propose that this Bug be renamed accordingly.
In reply to comment #12

> browser.preferences.instantApply set to 'true', which contrary to what Tony
> said is NOT the default.

According to http://kb.mozillazine.org/About:config_entries#Browser..2A , browser.preferences.instantApply defaults to true on all platforms except Windows. Maybe you're on Windows? I'm on Linux. And I just checked about:config in the latest nightlies of both BonEcho (Fx2) and Suiterunner (Sm2): the possible values (on this machine) are "user set: false" and "default: true".

But, like you, I'd still want new settings _not_ to be applied "instantly" if that pref is set to *false* either by default on Windows, or by explicit user action, as I did on my Linux box.
(In reply to comment #13)
> According to http://kb.mozillazine.org/About:config_entries#Browser..2A ,
> browser.preferences.instantApply defaults to true on all platforms except
> Windows. Maybe you're on Windows? I'm on Linux.

That'd explain it. You hadn't said in Comment #3 and I too hadn't specified.
Thanks for the clarification.
I want to note that bug 403699 was reopened. This bug may or may not get resolved with work there.  Waiting for mockups and a fix there.  I've already asked, and the dev on doesn't want to reopen this bug, at this time.
Thank you, Tracy.

Finally, they've admitted that the current UI sucks and are discussing a new version at bug 393509.
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.