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

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect, P5)

Description

[arni2033]

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

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

I can't reproduce on OS X or Linux nightlies. It must be a Windows-only issue.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

I'm on vacation, so I'll defer to Marco.

Comment 4

[Marco Bonardo [:mak]]

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?

Comment 5

[Neil Deakin]

Don't know. I don't see this behaviour.

Comment 6

[Marco Bonardo [:mak]]

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

Comment 7

[Ryan VanderMeulen (PTO, back July 27)]

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?

Comment 8

[Kan-Ru Chen [:kanru] (UTC+9)]

Neil can you try reproducing this on windows?

Comment 9

[Ryan VanderMeulen (PTO, back July 27)]

Looking likely that this is going to miss 51.

Comment 10

[Neil Deakin]

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.

Comment 11

[Marco Bonardo [:mak]]

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.