952753 - Australis: Toolbar buttons with type "menu-button" don't work correctly with Widget Overflow popup panel.

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[dave.r.wilson]

Attachment: PrintEdit-11.0b1d.xpi

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332

Steps to reproduce:

I am currently updating three of my add-ons (Print Edit, Tile Tabs & Zoom Page) to work with the Australis UI.  Print Edit and Tile Tabs each have a single toolbar button with type="menu-button".  Zoom Page has a <toolbaritem> containing three toolbar buttons all with type="button", and one of these buttons creates its own popup menu.

[Note: When the toolbar buttons are in the Menu Panel or Overflow Panel, I have found it necessary to add the noautoclose="true" attribute to all of the toolbar buttons.  Without this attribute, when a button is clicked and the drop-down menu is shown, the Menu Panel or Overflow Panel closes.  I'm not sure if it should be necessary to add this attribute.]

When the toolbar buttons are in the Overflow Panel, there are some focus problems causing unexpected closing of the Overflow Panel.  These problems affect the toolbar buttons of all three add-ons.  The simplest case to look at is the toolbar button of Print Edit.

There are several use cases:

First Use Case (works correctly)

1. Open Overflow Panel.
2. Click on toolbar button drop marker to show drop-down menu.
3. Click on browser page contents. Drop-down menu closes [as expected]. Overflow Panel stays open [as expected].
5. Repeat 3. Drop-down menu closes [as expected]. Overflow Panel stays open [as expected].

Second Use Case (browser window loses focus)

1. Open Overflow Panel.
2. Click on toolbar button drop marker to show drop-down menu.
3. Click on Overflow panel background. Drop-down menu closes [as expected]. Overflow Panel stays open [as expected]. Browser window loses focus [NOT EXPECTED].
4. Repeat 2.
5. Repeat 3. Drop-down menu closes [as expected]. Overflow Panel stays open [as expected].

Third Use Case (overflow panel closes unexpectedly)

1. Open Overflow Panel.
2. Click on toolbar button drop marker to show drop-down menu.
3. Click on Overflow panel background. Drop-down menu closes [as expected]. Overflow Panel stays open [as expected]. Browser window loses focus [NOT EXPECTED].
4. Repeat 2.
5. Click on browser page contents. Drop-down menu closes [as expected]. Overflow Panel closes [NOT EXPECTED].




Actual results:

In some circumstances (as described above), the Overflow Panel closes when a toolbar button drop-down menu is shown.





Expected results:

The Overflow Panel should stay open when a toolbar button drop-down menu is shown.

Comment 1

[dave.r.wilson]

I forgot to mention - all three use cases work correctly when the toolbar buttons are in the Menu Panel, instead of the Overflow Panel.

Comment 2

[:Gijs (out for now; he/him)]

(In reply to dave.r.wilson from comment #0)
> [Note: When the toolbar buttons are in the Menu Panel or Overflow Panel, I
> have found it necessary to add the noautoclose="true" attribute to all of
> the toolbar buttons.  Without this attribute, when a button is clicked and
> the drop-down menu is shown, the Menu Panel or Overflow Panel closes.  I'm
> not sure if it should be necessary to add this attribute.]

See bug 940307. We may also need that bug for some of the other issues in here.

Comment 3

[Paul Silaghi, QA [:pauly]]

Confirmed the use cases 2,3 from the comment 0, nightly 29.0a1(2014-01-28), win 7 x64

Comment 4

[Matthew N. [:MattN]]

I'm not sure how common it is for users to click in the overflow panel background.

Comment 5

[:Gijs (out for now; he/him)]

Attachment: don't use level='top', do use noautofocus, for australis overflow panel,

This fixes things for me, and is a pretty minimal change. Matt, thoughts?

Comment 6

[Matthew N. [:MattN]]

Comment on attachment 8382609 [details] [diff] [review]
don't use level='top', do use noautofocus, for australis overflow panel,

Review of attachment 8382609 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/customizableui/content/panelUI.inc.xul
@@ +220,5 @@
>  
>  <panel id="widget-overflow"
>         role="group"
>         type="arrow"
> +       noautofocus="true"

It seems the product is inconsistent regarding noautofocus and I don't know of guidelines on its use…

In this case since focusing the overflow panel is of no value AFAICT (the items are not focusable just like the rest of the toolbar buttons), I think this is fine.

Comment 7

[:Gijs (out for now; he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/719f34e66488

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/719f34e66488

Comment 9

[:Gijs (out for now; he/him)]

Comment on attachment 8382609 [details] [diff] [review]
don't use level='top', do use noautofocus, for australis overflow panel,

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Australis
User impact if declined: Focus changes and popups appearing/disappearing aren't consistent between the navbar's overflow panel and the main menu panel
Testing completed (on m-c, etc.): on m-c for a bit
Risk to taking this patch (and alternatives if risky): relatively low; makes things more consistent, less chance of breakage than leaving it as-is, IMO.
String or IDL/UUID changes made by this patch: none

Comment 10

[:Gijs (out for now; he/him)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7e40981b9e8d

Comment 11

[Ioana (away)]

Dave, can you please verify that this is fixed for you in Firefox 29?

Comment 12

[dw-dev]

I have tested the three use cases (in my original problem report) and I confirm that this bug has been fixed.

Dave