1181818 - UITours popups cause Firefox window to lose focus

Status: NEW

(Firefox :: Tours, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 0. Make sure Firefox Developer Edition is your default browser. (otherwise you'll get a popup about that at start-up time, which messes with this bug's reproducibility)

 1. Start Firefox Developer Edition with a fresh profile, e.g. type this in a terminal:
    mkdir /tmp/foo; ./firefox -profile /tmp/foo -no-remote

 2. Wait for the "Developer Tools" tour popup to appear.

 3. Try to do any keyboard command, e.g.: any of the following:
    - focus the URL bar with Ctrl+L
    - open a new tab with Ctrl+T.
    - resize the window with Alt+F8, or move it with Alt+F7
    - close the window with Alt+F4

 4. Now click anywhere on the window (even in the tour popup itself) and try to repeat step 3.

ACTUAL RESULTS:
The keyboard commands have *no effect*, until I perform step 4 (clicking somewhere). The Developer Tools tour popup seems to be stealing keyboard input & dropping it on the floor, until I've clicked. Or something.

EXPECTED RESULTS: Keyboard commands should work in a newly-opened Firefox window, just as they do in Nightly & Release (& in DevEdition after I've clicked somewhere)

Version: 41.0a2 (2015-07-08)

Comment 1

[Daniel Holbert [:dholbert]]

(I'm using 64-bit Ubuntu 15.04, with 64-bit Firefox Dev Edition.)

Comment 2

[Daniel Holbert [:dholbert]]

Actually, this bug happens repeatedly as I click through the tour -- each new popup triggers it again.

So e.g. after step 4 of my STR (after I've clicked), Ctrl+L works just fine. But then, if I click the green button on the popup, then it breaks again.

Comment 3

[Daniel Holbert [:dholbert]]

This is a papercut for me as a Gecko developer, when trying to briefly test something in Dev Edition using a fresh profile.

My normal muscle-memory for focusing the URL bar and typing a URL (Ctrl+L, type/paste, hit Enter) just has no effect at all on first launch (specifically for developer edition) which is frustrating.

dcamp, I recall you being involved w/ getting Dev Edition off the ground - do you know who might be the right folks to CC here would be?

Comment 4

[Dave Camp (:dcamp)]

Jeff can you track this down please?

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Thanks - I'll talk to Joe and get someone assigned. 

I think the behaviour we want is - the pop-up is dismissed once the user triggers a keyboard shortcut where the intent is to switch focus off the pop-up.

This will create false positive dismissals ( the user accidentally dismisses the tour pop-up ) but I think it's acceptable.

Joe: unsure who on the team is available to look at this - the first question to ask I guess is whether this is something specific to dev editon or generally a problem with the tour functionality. If it's more of a general problem we should loop in desktop UX.

Comment 6

[Brian Grinstead [:bgrins]]

Can you reproduce this if you open this page in a tab?  https://www.mozilla.org/en-US/firefox/40.0a2/firstrun/.  Just trying to narrow down if it's related to the tour running on startup or if it's an issue with the tour page itself.

Comment 7

[Daniel Holbert [:dholbert]]

Yes, loading that page does reproduce the problem.

Comment 8

[Brian Grinstead [:bgrins]]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> Yes, loading that page does reproduce the problem.

Oddly I can't reproduce this on win7, osx, or ubuntu (although I've checked mostly local builds).  A couple of more questions:

1) Do you see any errors in the Console on the page when this happens?
2) Can you reproduce the problem in a local build by loading that URL or is it only happening in a Dev Edition build?

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Brian Grinstead [:bgrins] from comment #8)
> Oddly I can't reproduce this on win7, osx, or ubuntu

I'm using gnome-shell (on Ubuntu) as my window manager -- that might be involved.  (In any case, I'm glad this is more of a niche issue than I initially suspected!)

> 1) Do you see any errors in the Console on the page when this happens?

Nope; only the mozilla-dino easter egg appears in the console.

> 2) Can you reproduce the problem in a local build by loading that URL or is
> it only happening in a Dev Edition build?

Yup, happens in Nightly & my own local m-c build.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screencast

Here's a screencast of the bug - as shown in the screencast, the issue seems to be that the Firefox window is losing focus every time a popup is spawned.

Comment 11

[Daniel Holbert [:dholbert]]

(i.e. the titlebar text fades to a darker color)  In my comment 0 STR, step 4 [clicking anywhere in the window or popup] makes the titlebar light up again.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Jeff Griffiths (:canuckistani) from comment #5)
> I think the behaviour we want is - the pop-up is dismissed once the user
> triggers a keyboard shortcut where the intent is to switch focus off the
> pop-up.
> 
> This will create false positive dismissals ( the user accidentally dismisses
> the tour pop-up ) but I think it's acceptable.

(I think this might already Just Work, given that things are fine after I've clicked somewhere [including on the popup].  I think the Firefox window & popup is just losing focus entirely for some reason.)

Comment 13

[Brian Grinstead [:bgrins]]

And finally, one more question - does this also happen on other tours for you (i.e. https://www.mozilla.org/en-US/firefox/39.0/tour/)?

Comment 14

[Daniel Holbert [:dholbert]]

Yup, same issue there.

Comment 15

[Brian Grinstead [:bgrins]]

Seems like it may be related to the gnome-shell window manager but it'd be good to have verification that this isn't affecting all Ubuntu users

Comment 16

[Daniel Holbert [:dholbert]]

Possibly related to bug 795817 (an extension's popups causing what sounds like the same sort of problem).

Comment 17

[Brian Grinstead [:bgrins]]

Clearing Joe's ni since this doesn't seem to be Dev Edition specific

Comment 18

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Yeah, this kind of smells like a gtk-level problem.

One thing I think we should consider for the tour code though is the ability to bind esc to dismiss the popup - this currently doesn't work and could be an intuitive way to dismiss the popup for most developers?

Comment 19

[Matthew N. [:MattN]]

It's a known issue that panels/popups with @noautohide are wonky on Linux with various window managers and tour infoPanels use @noautohide. Depending on the desired UX, we could an option to not use @noautohide. @noautohide popups are treated similar to top-level windows on Linux and I think that's why the main window loses focus.

We've been fighting with panels on Linux since the beginning of UITour for Australis btw. It really needs platform attention but @noautohide is rare outside UITour.

(In reply to Jeff Griffiths (:canuckistani) from comment #18)
> One thing I think we should consider for the tour code though is the ability
> to bind esc to dismiss the popup - this currently doesn't work and could be
> an intuitive way to dismiss the popup for most developers?

That seems reasonable too as long as that doesn't cause other problems (e.g. if ESC already does something else).

Comment 20

[Alex Gibson [:agibson]]

(In reply to Matthew N. [:MattN] from comment #19)
> It's a known issue that panels/popups with @noautohide are wonky on Linux
> with various window managers and tour infoPanels use @noautohide. Depending
> on the desired UX, we could an option to not use @noautohide. @noautohide
> popups are treated similar to top-level windows on Linux and I think that's
> why the main window loses focus.
> 
> We've been fighting with panels on Linux since the beginning of UITour for
> Australis btw. It really needs platform attention but @noautohide is rare
> outside UITour.

If this fixes the issue described in this bug, then adding an @noautohide option gets a +1 from me. This would also help us out in other situations, as we currently have to work pretty hard to manually work around certain behaviors in some tours/pages.

> (In reply to Jeff Griffiths (:canuckistani) from comment #18)
> > One thing I think we should consider for the tour code though is the ability
> > to bind esc to dismiss the popup - this currently doesn't work and could be
> > an intuitive way to dismiss the popup for most developers?
> 
> That seems reasonable too as long as that doesn't cause other problems (e.g.
> if ESC already does something else).

I think this might cause some issues in other tours. I know we do use `esc` as an exit shortcut in some places already, but if this was baked-in behavior to tour popups then web pages would probably also need some way to know when `esc` was triggered, else they might get stuck in an unknown state (we already need a callback for when someone clicks the little (x) for example).