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

NEW
Unassigned

Status

()

defect
P5
normal
3 years ago
Last year

People

(Reporter: arni2033, Unassigned)

Tracking

(Blocks 1 bug, {regression})

48 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(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)

Details

(Whiteboard: [fxsearch])

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160426044609
STR:
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:
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=9774863180f92d75e7851f138bed71fe9828122a&tochange=45f98cbddc015c5659abe141de0b8fa6bd534051
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
You need to log in before you can comment on or make changes to this bug.