>>> 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
I can't reproduce on OS X or Linux nightlies. It must be a Windows-only issue.
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.
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?
Don't know. I don't see this behaviour.
(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.
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?
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.
You need to log in before you can comment on or make changes to this bug.