Closed Bug 1268735 Opened 4 years ago Closed 1 year ago

Scratchpad window opens in background if I press Shift+F4 in urlbar after hiding suggestions with Right key


(Firefox :: Address Bar, defect, P5)

48 Branch



Tracking Status
firefox47 --- unaffected
firefox48 --- wontfix
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- fix-optional
firefox53 --- fix-optional
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- fix-optional


(Reporter: arni2033, Unassigned)


(Depends on 1 open bug)


(Keywords: regression, Whiteboard: [fxsearch])

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160426044609
1. Type "asdf" in urlbar
2. Press Right key to hide suggestions
3. Press Shift+F4

AR:  Scratchpad window focused, but placed in background
ER:  Scratchpad should appear in foreground

This is regression from bug 1264983. Regression range:
Flags: needinfo?(adw)
Blocks: 1276120
Blocks: 1262507
I can't reproduce on OS X or Linux nightlies. It must be a Windows-only issue.
Flags: needinfo?(adw)
Priority: -- → P3
Whiteboard: [fxsearch]
Version: unspecified → Trunk
Panos, could you please update the status of 48, 49, 50 as wontfix/fix-wanted/affected, depending on how much we need the fix in any of these releases, so that the triage group knows what the plan is.
Flags: needinfo?(past)
I'm on vacation, so I'll defer to Marco.
Flags: needinfo?(past) → needinfo?(mak77)
it's Windows-only indeed, and doesn't seem to happen for any window, for example it doesn't happen for the Library, or for the Browser Console.
I'm not sure how the Scratchpad window differs from the others.

Since it's limited to specific windows, I don't think it's critical enough. We'll take a fix if we're in time with the schedule, would be nice to have a fix in Nightly.

Neil, any idea what may cause a window like Scratchpad to be bounced back to background when it's open from a shortcut, after a level="parent" panel is closed? What may cause a similar behavior only for certain windows?
Flags: needinfo?(mak77) → needinfo?(enndeakin)
Priority: P3 → P2
Don't know. I don't see this behaviour.
Flags: needinfo?(enndeakin)
(In reply to Neil Deakin from comment #5)
> Don't know. I don't see this behaviour.

Are you on Windows?
Just click on the urlbar, type something, click again on the urlbar (to dismiss the panel), shift+F4.
Flags: needinfo?(ryanvm)
This is indeed quite annoying and I've confirmed that it still reproduces on current nightlies on Win10. Neil, can you please try reproducing on Windows?
Flags: needinfo?(ryanvm) → needinfo?(enndeakin)
Version: Trunk → 48 Branch
Neil can you try reproducing this on windows?
Looking likely that this is going to miss 51.
I managed to reproduce this sometimes. When it occurs, the autocomplete popup is being reopened while the Scratchpad window is being opened.

This is the JS stack at the time:

File: chrome://global/content/bindings/popup.xml Name: openPopup Line: 51
File: chrome://browser/content/urlbarBindings.xml Name: _openAutocompletePopup Line: 1578
File: chrome://browser/content/urlbarBindings.xml Name: openAutocompletePopup Line: 1512
File: chrome://global/content/bindings/autocomplete.xml Name: openPopup Line: 393
File: chrome://global/content/bindings/autocomplete.xml Name: set_popupOpen Line: 103
File: chrome://global/content/bindings/autocomplete.xml Name: detachController Line: 384
File: chrome://global/content/bindings/autocomplete.xml Name: onxblblur Line: 694

This happens when the main browser window is being deactivated as evidenced by the last line here (blur handler) and it gets called just after Windows sends WM_KILLFOCUS.
The input field of the auto complete controller is being set to null during detachController.

From a brief look at nsAutoCompleteController::SetInput, it looks like :StopSearch will open the popup if a search is still pending. That matches the stack above and suggests why this might happen only intermittently. It should likely cancel that instead when we know we are blurring the autocomplete field.

I'll leave this for mak or someone else to investigate further.
Flags: needinfo?(enndeakin) → needinfo?(mak77)
Thanks, that sounds like useful feedback to start an investigation, the StopSearch behavior looks interesting. So in practice StopSearch invokes PostSearchCleanup that may invoke OpenPopup().
We can very likely fix the setInput behavior here to disallow opening when input is being set to null.
The frontend could additionally disallow the opening if the input field doesn't have focus.
Flags: needinfo?(mak77)
Priority: P2 → P3
Priority: P3 → P5
Closed: 1 year ago
Depends on: quantumbar
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.