1290011 - Prevent the "New Bookmark" menu from timing out and creating the bookmark in a default location

Status: RESOLVED DUPLICATE of bug 1206133

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

Description

[fios]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

I go through the same procedure that I always have (Hit ALT to get the classic menu -> Bookmarks -> Add Bookmark).


Actual results:

The menu to pick a destination for the bookmark is shown, but while I'm still looking at it and trying to decide where to click next, the menu disappears and the bookmark has been added to a default location rather than to the folder that I wanted to pick.

I originally asked this as a question:

https://support.mozilla.org/en-US/questions/1132475


Expected results:

The menu stays where it it, so I can pick a destination folder for the bookmark.

Comment 1

[arni2033]

I too have this problem. This is regression from bug 1219794.

@ Verdi :
Is it intentional that browser interrupts user's thinking process and closes the panel randomly?

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Too late for 48

Comment 3

[Verdi [:verdi] Best to slack me]

(In reply to arni2033 from comment #1)
> Is it intentional that browser interrupts user's thinking process and closes
> the panel randomly?

It is an intentional change - see Bug 1219794. We now show the panel and "page bookmarked" message when you click the star in the toolbar. At the same time, we didn't want to remove the ability to do one-click bookmarking so we set a 3 second time out on the panel, after which it closes unless the user hovers over it or interacts with it in some way. 

It sounds to me that in this case, the problem is that the time out on the panel is not long enough if you use the menu command or keyboard shortcut. I suggest we increase the time out on the panel when you use the menu command or keyboard shortcut. Maybe 5 seconds is enough.

Comment 4

[Gerry Chang [:gchang]]

Hi :jaws, 
Since you fixed the bug 1219794 and this bug is a behavior change, could you take a look at this bug and consider what Verdi mentioned in comment #3?

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Hi Gerry, thanks for the needinfo. I'm not sure why we would increase the timeout for menu command or keyboard shortcut, I don't see why users coming from those areas would need more time than others, or in the converse, why users who use the mouse would need less time.

It seems no timeout will be "good enough" for the "I just created a bookmark and now I want to think about where to put it" use-case. People who complain that 3 seconds isn't long enough will still complain when 5 seconds isn't long enough, etc. 

Prior to bug 1219794, we didn't open the menu when the bookmark was first created. The menu would only open the second time either the keyboard shortcut was pressed or the star was clicked. We don't auto-close the menu the second time that it is open, and moving the bookmark from one folder to another while the menu is open is very easy.

In summary,

Part 1:
>               |Pre-bug 1219794  | Post-bug 1219794
> ----------------------------------------------------
> New bookmark  | no menu opened  | menu opened, 3s timeout 
> Edit bookmark | menu opened     | menu opened, no timeout

Part 2:
Users who wanted to select a folder pre-bug 1219794 would either click the star twice or hit the keyboard shortcut twice. 

>                           |Pre-bug 1219794                       | Post-bug 1219794
> -------------------------------------------------------------------------------------------
> Click star to edit        | two clicks to open w/ no timeout     | three clicks to open w/ no timeout
> Keyboard shortcut to edit | two presses of shortcut w/ no timeout| two presses of shortcut w/ no timeout

So it seems the only bug here is that it now takes three clicks on the star to keep the menu open without a timeout. There is no change to keyboard users.

Comment 6

[Verdi [:verdi] Best to slack me]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5)
> I'm not sure why we would increase the
> timeout for menu command or keyboard shortcut, I don't see why users coming
> from those areas would need more time than others, or in the converse, why
> users who use the mouse would need less time.
> 

I think it has to do with how far you have to potentially move the pointer. If you click the star, you just have to move the pointer a few mm to reach the panel. If you use the menu command or keyboard shortcut you may have to traverse most of the screen.

> 
> Prior to bug 1219794, we didn't open the menu when the bookmark was first
> created. The menu would only open the second time either the keyboard
> shortcut was pressed or the star was clicked. We don't auto-close the menu
> the second time that it is open, and moving the bookmark from one folder to
> another while the menu is open is very easy.

We have all kinds of inconsistencies here. Prior to this change, we had a different behavior for the star. Previously we only showed the panel (the first time) if you used the menu or keyboard command and it would not time out. Now we always show the panel and it times out.

Comment 7

[arni2033]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5)
> People who complain that 3 seconds isn't long enough will complain that 5 seconds isn't long enough
Exactly. I was going to suggest 100 seconds timeout - that would be good enough.
I wrote the following text in advance in case nobody would report this bug. It explains use case a bit better and also explains new inconsistency added in bug 1219794 (Note 2, Note 3).

STR_1:
1. Open https://helpx.adobe.com/flash/kb/flash-object-embed-tag-attributes.html in a new tab
2. Scroll the page to the end, as if you've read the whole article
3. Press Ctrl+D to bookmark the page (make sure mouse is still outside of "New bookmark" popup)
4. Scroll the page to the top via mouse wheel, and start looking for a paragraph that mentions 'wmode'

AR:  After several seconds of Step 4 "new bookmark" popup disappears
ER:  Either X or Y or Z or T   (X is the best option)
 X) The panel shouldn't hide to allow me to read the article, like it did before regression bug1219794
 Y) The panel should only hide for THE FIRST time when user creates bookmark
   (to explain to new users that "it's safe to close the panel" or whatever Firefox developers want to
    explain by randomly hiding the panel. It's enough to do that only once)
 Z) Bookmarks panel should also "auto-close" if I edit existing bookmark via Ctrl+D (consistency)
 T) All panels (especially  "Share this page",  "Save to Pocket")  should do the same thing to
    explain to user that this is not a bug, i.e. this use case was broken intentionally. (consistency)


Notes:
1) Use case: In Step 3 my thoughts are "I'm going to add the reason I'm bookmarking the article in the
   bookmark's name. Wait, how many possible values does 'wmode' have? THIS is why I'm saving the page"

2)[Explanation for Y,Z,T]   This obtrusive behavior was implemented in bug 1219794 without any reason.
   The only case when it _could_ be useful for end user is when user is new to the whole PC thing, and
   he doesn't know how to properly close panels. However, there was no statistics gathered in
   bug 1219794, it was just broken because one person thought it's OK to break UX to make bookmarks
  "easier to understand" (very ironic). Then why not all panels work in "easier to understand" way?

3) Without   X or Y or T   it may seem that ANY popup will randomly hide
   if user won't rapidly move mouse over it, while it's not true.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

I think arni makes good points here. We made the bookmarks panel autclose because the pocket panel autocloses, but we don't have autoclosing panels anywhere else in Firefox. The permissions panels don't close, neither does downloads, share this page, firefox menu, etc.

I checked Facebook and their panels for friend requests, messages, and notifications don't autoclose either.

Verdi, are you OK with backing out the bookmark panel autoclosing?

Comment 9

[Marco Bonardo [:mak]]

Imo, the autoclosing was mostly to retain the original one-click bookmarking concept, having to dismiss the panel makes one-click-cookmarking not exactly one-click, and could end up being annoying. At that point we may have better interaction alternatives (Boriss time ago designed a different bookmarking interaction that was sort of a 2-click-bookmarking).

I think we should autoclose only when the user CLICKS the star with the mouse, and not autoclose when it is opened through a shortcut or a menu.
The mouse users can still use double-click to avoid autoclose.

Comment 10

[Verdi [:verdi] Best to slack me]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8)
> Verdi, are you OK with backing out the bookmark panel autoclosing?

No. 
We used the pocket autoclose time as the basis for the time for the bookmarks panel but the purpose of autoclosing was to preserve the ability to bookmark something with one click.

Comment 11

[fios]

I think autoclosing is generally a very bad idea. It is confusing as hell for the user. There are people out there who need a long time to read and understand any user interface whatsoever, and to have things disappearing on them will make them think that they have done something wrong or that they broke their computer. So, as has already been mentioned in this bug, no mater how long you increase the time out, there will always be some users who complain, and they will have very good reason to.

I vote for not opening the menu at all with first click on the star. With second click on the star, open without timeout. With any other access method, open without timeout.

Comment 13

[Marco Bonardo [:mak]]

Verdi, what do you think of comment 10? Could we limit autoclosing to the single mouse click case?

Comment 14

[sworddragon2]

If the conditional autoclosing is intended the easiest solution would be possibly to put the timeout behind a preference. Users can adjust the timeout in seconds to match their likings. They could also completely disable showing the notification with a value of 0 in case they do not need it for example on creating bookmarks and they could also revert the old behavior with a value of -1 which causes an infinite timeout.

Possibly too obvious to implement this?^^

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to sworddragon2 from comment #14)
> If the conditional autoclosing is intended the easiest solution would be
> possibly to put the timeout behind a preference. Users can adjust the
> timeout in seconds to match their likings. They could also completely
> disable showing the notification with a value of 0 in case they do not need
> it for example on creating bookmarks and they could also revert the old
> behavior with a value of -1 which causes an infinite timeout.
> 
> Possibly too obvious to implement this?^^

In a nutshell, it's not "too obvious to implement this". It just gets to the point where if we have prefs that can change the behavior of every UI element of the browser (show old awesomebar results, show old search bar dropdown, keep old bookmark behavior, keep square tabs, allow separating the stop/go button, allow separating the back/forward/location bar, etc), then we get in to a state where it becomes impossible to test and support all possible configurations of the browser. We need sensible defaults and good behavior out of the box. Each configuration option brings with it added maintenance cost and hidden bugs.

Comment 16

[sworddragon2]

Ah, Jared, you again... :)

This is a valid argument but in my opinion maintaining options should not be considered a problem as they are a huge feature and something that helped making Firefox big in the past. The engineers should try its best to find a solution for easy maintability of such a huge flexibility.

The marketshare of Firefox is constantly falling since years and only around 30% of its peak marketshare. Chrome is a strong competitor but removing the flexibility of Firefox is a big fault why this happened. I have heard of a very lot of people even outside this tracker whose claimed about the reduced flexibility, namely even some of the examples you mentioned as a major issue which caused many of them to change the browser.

Even just a "small" thing like this (if not solved sufficiently) will be the final straw for several users again causing them to choose another browser.

Comment 17

[fios]

A good default behavior is always better than having a bazillion options - at least when the user has to choose all of them. Have in the about thingy what pleases the knowledgeable, but for the average user, the less options, the better.

Not making up our minds about what the best option is just shifts the problem to the user, so they will have to do the work for us.

Comment 18

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Marco Bonardo [::mak] from comment #13)
> Verdi, what do you think of comment 10? Could we limit autoclosing to the
> single mouse click case?

I am in favor of limiting the autoclosing to the single mouse click case. I'm waiting to hear from Verdi though.

Comment 20

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Marco can you help find someone to take this on for 53? We could still uplift a patch to 52, too.

Comment 21

[Marco Bonardo [:mak]]

I think this change was under responsibility of the QX team.
So forwarding the request to Dolske.  If we cannnot find someone soon, we'll see if we can find resources in the Awesomesearch Team.

Regardless, this is still pending a needinfo on UX (See Comment 18)

Comment 22

[Verdi [:verdi] Best to slack me]

Stephen Horlander and I discussed this and decided that we should leave things as they are (wontfix this).

Comment 23

[Lina Butler (ex-Mozilla)]

That's unfortunate. :-( I rename most of my bookmarks, and the panel frequently auto-dismisses as I'm typing, or choosing a different folder. I can click the star again to bring up the panel, and it stays visible after that...but the experience feels sloppy and frustrating. I know most people don't file or rename bookmarks, so I can understand keeping things as they are, but is there any chance you're willing to reconsider?

Comment 24

[Verdi [:verdi] Best to slack me]

(In reply to Kit Cambridge [:kitcambridge] from comment #23)
> That's unfortunate. :-( I rename most of my bookmarks, and the panel
> frequently auto-dismisses as I'm typing, or choosing a different folder. I
> can click the star again to bring up the panel, and it stays visible after
> that...but the experience feels sloppy and frustrating. I know most people
> don't file or rename bookmarks, so I can understand keeping things as they
> are, but is there any chance you're willing to reconsider?

That would be a bug. I just tried to reproduce and couldn't. It's designed to stay open indefinitely if you interact with it any way, including just putting the pointer over it.

Comment 25

[fios]

(In reply to Verdi [:verdi] from comment #24)
> (In reply to Kit Cambridge [:kitcambridge] from comment #23)
> > That's unfortunate. :-( I rename most of my bookmarks, and the panel
> > frequently auto-dismisses as I'm typing, or choosing a different folder. I
> > can click the star again to bring up the panel, and it stays visible after
> > that...but the experience feels sloppy and frustrating. I know most people
> > don't file or rename bookmarks, so I can understand keeping things as they
> > are, but is there any chance you're willing to reconsider?
> 
> That would be a bug. I just tried to reproduce and couldn't. It's designed
> to stay open indefinitely if you interact with it any way, including just
> putting the pointer over it.

Seems like that part of the bug has been fixed - at least for me. What is still confusing about this menu is that it always has a "Remove 1 link" button - that button should only be there if this has been bookmarked before. I guess that problem here is that Firefox already creates a bookmark as soon as this menu is created, rather than adding it when the menu is being closed?

Comment 26

[Marco Bonardo [:mak]]

(In reply to fios from comment #25)
> I guess that problem here is that Firefox already creates a bookmark
> as soon as this menu is created, rather than adding it when the menu is
> being closed?

Yes, it's an instant-apply dialog.

Comment 27

[Marco Bonardo [:mak]]

we seem to be missing good STR here. Kit maybe you could help finding them since you are still suffering this issue?

Comment 28

[Lina Butler (ex-Mozilla)]

Sure thing. Unfortunately, I don't have consistent STR, either. "Sometimes it auto-dismisses, sometimes it doesn't" is unhelpful. (Though it never auto-dismisses the second time, if I restore the star UI after the first dismissal).

Is there any logging I can enable to see what's going on? If not, where does the code for the auto-dismiss timer live? I could add some dumps and see if that helps track this down.

Comment 29

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Kit Cambridge [:kitcambridge] from comment #28)
> Sure thing. Unfortunately, I don't have consistent STR, either. "Sometimes
> it auto-dismisses, sometimes it doesn't" is unhelpful. (Though it never
> auto-dismisses the second time, if I restore the star UI after the first
> dismissal).
> 
> Is there any logging I can enable to see what's going on? If not, where does
> the code for the auto-dismiss timer live? I could add some dumps and see if
> that helps track this down.

Look for _autoCloseTimer in browser-places.js

Comment 30

[redmiatazoomzoom]

(In reply to Kit Cambridge [:kitcambridge] from comment #23)
> That's unfortunate. :-( I rename most of my bookmarks, and the panel
> frequently auto-dismisses as I'm typing, or choosing a different folder. I
> can click the star again to bring up the panel, and it stays visible after
> that...but the experience feels sloppy and frustrating. I know most people
> don't file or rename bookmarks, so I can understand keeping things as they
> are, but is there any chance you're willing to reconsider?

Ditto.

On the initial creation of the bookmark using the menu (Bookmarks -> Add Bookmark) or with the Ctrl+D shortcut, mouse hovering or clicking/typing within the bookmark dialogue box sometimes has no effect on this auto-dismissal / 3-second timeout "bug." It rarely stays on the screen long enough for me, but once in a while, it stays there long enough - it's intermittent. However, it always stays indefinitely on the screen after bringing it up for a SECOND time to edit the bookmark's name/location.

(In reply to Verdi [:verdi] from comment #24)
> (In reply to Kit Cambridge [:kitcambridge] from comment #23)
> > That's unfortunate. :-( I rename most of my bookmarks, and the panel
> > frequently auto-dismisses as I'm typing, or choosing a different folder. I
> > can click the star again to bring up the panel, and it stays visible after
> > that...but the experience feels sloppy and frustrating. I know most people
> > don't file or rename bookmarks, so I can understand keeping things as they
> > are, but is there any chance you're willing to reconsider?
> 
> That would be a bug. I just tried to reproduce and couldn't. It's designed
> to stay open indefinitely if you interact with it any way, including just
> putting the pointer over it.

As I have described, this is an intermittent bug which cannot always be replicated. Please fix it!

Comment 31

[Terrell Kelley]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #15)
> (In reply to sworddragon2 from comment #14)
> > If the conditional autoclosing is intended the easiest solution would be
> > possibly to put the timeout behind a preference. Users can adjust the
> > timeout in seconds to match their likings. They could also completely
> > disable showing the notification with a value of 0 in case they do not need
> > it for example on creating bookmarks and they could also revert the old
> > behavior with a value of -1 which causes an infinite timeout.
> > 
> > Possibly too obvious to implement this?^^
> 
> In a nutshell, it's not "too obvious to implement this". It just gets to the
> point where if we have prefs that can change the behavior of every UI
> element of the browser (show old awesomebar results, show old search bar
> dropdown, keep old bookmark behavior, keep square tabs, allow separating the
> stop/go button, allow separating the back/forward/location bar, etc), then
> we get in to a state where it becomes impossible to test and support all
> possible configurations of the browser. We need sensible defaults and good
> behavior out of the box. Each configuration option brings with it added
> maintenance cost and hidden bugs.

This logic is faulty. The entire point of about:config is that any change you make in it may not be supported. That's why there's (by default) a big disclaimer telling you that you could mess things up.

This is a numeric concept--the number of seconds or milliseconds to keep the bookmark dialog open. There is no reason that properly designed code should ever fail on any number within reasonable bounds (e.g. all 32-bit integers or such). And there is no reason it should take a whole new release to test different numbers to see what actually creates the best experience. (or possibly "experiences" if you decide to support more than one configuration.)

I've been watching Firefox's development for a long time, and it seems very atypical that such a pref was not implemented from the get-go. I was so sure there was one that I told someone I would try and find it. 

And that's not getting into how, with the RapidRelease development cycle, it's a good idea to be able to temporarily pref off anything that has the potential for bugs. It seems there is a problem where the panel does not correctly detect that the user has interacted with it, which should stop any timeout. 

In summary, I propose giving it an integer pref in about:config. And a separate temporary boolean that disables the timer, which should remain until all bugs are worked out. 

Support should eventually only be for the default value.

Comment 32

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #27)
> we seem to be missing good STR here. Kit maybe you could help finding them
> since you are still suffering this issue?

This bug was opened to completely remove unwanted "improvement" «automatically remove bookmarks panel after 3 seconds w/o user activity above "new bookmark" panel». STR are in comment 7.

It is unclear why because of some Pocket users I have to deal with this regression...
It is unclear why I as keyboard user have to deal with UX team decision to implement one-CLICK UX.
It is unclear what should I press to prevent it from timing out. Pressing Ctrl+D twice doesn't work,
 preessing Ctrl+D 3 times doesn't work. If browser makes me do some "tricks", I won't enjoy this UX.

Comment 33

[fios]

I ran into the bug again a few days ago on a friend's Windows machine - The menu closed on me while I was trying to select the bookmark's destination.

So, it happens very rarely, but it's still there -> pain in the butt to debug. Good luck chasing it!

Comment 34

[David]

Major annoyance this is, and you can't even agree if it is to be fixed or not. Why not then just make it possible to select timeout in about:config. The reasoning behind refusing that does not hold water. If you really believe using about:config is not a good idea then please add this parameter among the settings that can be changed under the tools tab. These kinds of annoyances are a major reason why people change browser. It has been months.

Comment 35

[Alice0775 White]

[Tracking Requested - why for this release]:Bad user experience due to bug 1219794. Web page can steal user input when user is typing keyboard

Comment 36

[Alice0775 White]

:jaws
you could not fix the regression for a long period.
It need to back out the bunch of patch related to Bug 1219794.

Comment 37

[Alice0775 White]

How easy to reproduce the bug. See screen capture https://youtu.be/hHZG_MISJR0
Web page steals key typing when I add bookmark.

Comment 38

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Alice0775 White from comment #36)
> :jaws
> you could not fix the regression for a long period.
> It need to back out the bunch of patch related to Bug 1219794.

I have watched your video multiple times and cannot reproduce it. We clear the timer on keypress. The timer restarts when the mouse leaves the popup. In your video the timer should have been cleared when the 'a' key was pressed, so there is a bug here but I can't get it to close.

I'm creating a new bookmark, then moving the mouse across the popup and then out of the popup, then pressing 'a' and the popup doesn't close. I can only get it to close by moving the mouse across the popup and then out of it and waiting 3 seconds.

Comment 39

[Alice0775 White]

annoying bug.

please backed out the offending patch if you could not fix this.

Comment 40

[feqwix]

Unexpected behaviour:

In any non-bookmarked page, hit ``CTRL + D``. Then, fast, type a letter (e.g. ``f``) and wait.
The bookmarks dialog appears with the ``f`` in the ``Tags`` (or ``Name``) field.
After some seconds, the dialog closes.

The dialog is not detecting this interaction thus not cancelling the timeout.

I use Tags a lot and with this behaviour I'm not able to read all the tag suggestions after typing a single letter.

- v51.0.1.
- Mouse is always away of the dialog.

Comment 41

[redmiatazoomzoom]

I noticed also that it prematurely times out if I quickly move the mouse to the dialog box immediately after clicking the bookmark option from the main menu.

If I leave the mouse perfectly still upon clicking "bookmark this page" and then wait until after the dialogue box has fully displayed before moving my mouse over to it to begin interacting with it, the dialogue box will remain until I am finished with it.

Therefore, I no longer believe it is an intermittent problem and this is the process to replicate the problem: moving the mouse to the dialogue box before/while it opens fails to trigger the mouse-over detection so that it'll cancel the 3-second timeout.

The end.

Comment 42

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to feqwix from comment #40)
> Unexpected behaviour:
> 
> In any non-bookmarked page, hit ``CTRL + D``. Then, fast, type a letter
> (e.g. ``f``) and wait.
> The bookmarks dialog appears with the ``f`` in the ``Tags`` (or ``Name``)
> field.
> After some seconds, the dialog closes.
> 
> The dialog is not detecting this interaction thus not cancelling the timeout.
> 
> I use Tags a lot and with this behaviour I'm not able to read all the tag
> suggestions after typing a single letter.
> 
> - v51.0.1.
> - Mouse is always away of the dialog.

I can't reproduce this (I'm testing on Nightly 53.0a1 (2017-01-15) (64-bit) Windows). What operating system are you testing on? 

(In reply to redmiatazoomzoom from comment #41)
> I noticed also that it prematurely times out if I quickly move the mouse to
> the dialog box immediately after clicking the bookmark option from the main
> menu.
> 
> If I leave the mouse perfectly still upon clicking "bookmark this page" and
> then wait until after the dialogue box has fully displayed before moving my
> mouse over to it to begin interacting with it, the dialogue box will remain
> until I am finished with it.
> 
> Therefore, I no longer believe it is an intermittent problem and this is the
> process to replicate the problem: moving the mouse to the dialogue box
> before/while it opens fails to trigger the mouse-over detection so that
> it'll cancel the 3-second timeout.

I filed bug 1335043 for this and should have a patch posted shortly.

Comment 43

[feqwix]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #42)

> I can't reproduce this (I'm testing on Nightly 53.0a1 (2017-01-15) (64-bit)
> Windows). What operating system are you testing on? 

Just tested this on Nightly 54.0a1 (2017-01-30) (32-bit) (Windows) and the behaviour changed: no text can be entered in any field until the bookmarks dialog is fully painted. I couldn't reproduce the issue described in my previous comment, so I think it may have been fixed.

Comment 44

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to feqwix from comment #43)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #42)
> 
> > I can't reproduce this (I'm testing on Nightly 53.0a1 (2017-01-15) (64-bit)
> > Windows). What operating system are you testing on? 
> 
> Just tested this on Nightly 54.0a1 (2017-01-30) (32-bit) (Windows) and the
> behaviour changed: no text can be entered in any field until the bookmarks
> dialog is fully painted. I couldn't reproduce the issue described in my
> previous comment, so I think it may have been fixed.

Thank you for your quick response. Could you please test using mozregression? Using mozregression we will be able to find exactly when this got fixed, and then we can make sure to get that fix shipped out to users sooner (if possible). You can read more about mozregression at http://mozilla.github.io/mozregression/

Comment 45

[feqwix]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #44)

Here's the result of the mozregression *bug fix* bisection:

INFO : Narrowed inbound regression window from [c0be513c, 36dbc4e2] (3 revisions) to [c0be513c, 8468a31d] (2 revisions) (~1 steps left)
DEBUG : Starting merge handling...
DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=8468a31dcb9441bbdd8a1f4f27a982409c677f0a&full=1
DEBUG : Found commit message:
Bug 1305360 - Part 2: Add an exception handler to annotate memory protection crashes in regions of interest. r=jandem, r=luke

INFO : The bisection is done.
INFO : Stopped

Comment 46

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to feqwix from comment #45)

Thank you, it looks like it was fixed by bug 1206133, which will ship with Firefox 52 which is in Firefox Beta already. We won't make any changes to release Firefox unless it is a major security issue so this will have to wait until Firefox 52 to be fixed on Release. Thank you for your help!

Comment 47

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

If this was fixed by bug 1206113 we can mark it as a duplicate.

Comment 48

[sworddragon2]

Does the patch in the linked ticket really solve the "Actual results:" from this startpost? I see only changes made into tests/* and thus wouldn't think so.

Comment 50

[King Canute]

"People who complain that 3 seconds isn't long enough will complain that 5 seconds"

This is typical of the incredibly arrogant attitude that has come to characterize the Moz/Ffx dev community. I don't expect any constructive response, but FWIW:

The dialog in question shows for LESS THAN 1 second in Ffx v. 53.0.3, under Ubuntu Xenial, 64 bit. This whole project is infested with bad attitude & coasting on past glory. Time to move on. I just installed Palemoon. Looks good so far.

Comment 51

[Sebastian H.]

Soo... I know this is supposed to be a duplicate of a fixed bug, but the behavior is still there. FF 102.0.1 (64 bit) on macOS Monterrey (12.4).

It's been annoying me for years. Serioulsy, who on earth thought this would be a good idea? What other application has an invisible (!) timeout on a user-triggered dialog and performs some dubious "default action" if the user doesn't react fast enough? That's just insane UX to me.

Comment 52

[Sebastian H.]

Soo... I know this is supposed to be a duplicate of a fixed bug, but the behavior is still there. FF 102.0.1 (64 bit) on macOS Monterrey (12.4).

It's been annoying me for years. Serioulsy, who on earth thought this would be a good idea? What other application has an invisible (!) timeout on a user-triggered dialog and performs some dubious "default action" if the user doesn't react fast enough? That's just insane UX to me.

Edit: sorry for ranting, it's just it drives me mad still.