434097 - RC 1 -- left-clicking on Customize Toolbar popup doesn't give app focus to Firefox

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Example of the split colour on the nav bar

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9) Gecko/2008051202 Firefox/3.0

STR:

1. Have a Firefox window open and click somewhere else so that the window is visible and out of focus.  The Navigation and Bookmarks toolbars should be light in colour.

2. I use the two finger on trackpad for secondary clicks on a MBP and so when I do this to click on the toolbar of the unfoccused window and select customize, then drag something new to to toolbar and select done (the window must stay out of focus the whole time, don't click on it yet)

3. Once you've clicked "Done" go and click on the top of the Navigation Bar and you should get a split colour where the top of the Nav bar is light and the bottom is the darker gray.

See attached screenshot for details.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Another example - though not able to reproduce

This is the example of what tipped me off to the bug - but I wasn't able to reproduce this variation again.

Comment 2

[Markus Stange [:mstange]]

This is really really weird.

I can reproduce it, but only once per session. It looks like window focus gets messed up completely - for example, the menubar shows "Firefox", but no firefox window has main state (you can tell by the color of the close/min/zoom-buttons) and mouse wheel scrolling has no effect.
You can restore "normal" focus by switching to another application and back, but that doesn't solve everything; I've noticed that dragging files from Finder to Firefox (like Addon-.jars or html-Files) stops working.
Bug 416455 sounds kind of similar.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

I can reproduce this more than once per session (using a Microsoft
mouse on OS X 10.5.2).  The symptoms are very much like bug 416455 --
in step 3 (from comment #0) the main menu doesn't get switched back to
the Firefox menu.

So this must be a variant of bug 416455 ... though it's not a dup.

And for that reason it's almost certainly a Cocoa widgets bug.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Here's a simplified STR:

1) Right-click or control-click on the Navigation Toolbar and choose
   Customize (in the context menu that pops up) -- a popup window will
   appear with "You can add or remove items by dragging to or from the
   toolbars" at the top.

2) Click on the Desktop -- Firefox will lose the application focus,
   and the main menu will change from the Firefox menu to the Finder
   menu.

3) Click somewhere on the Customize popup window -- Firefox will
   (partially) regain the application focus, but the Firefox menu
   won't be restored.

   Clicking on the popup window's Done button will make it disappear,
   but now clicking anywhere in the browser window (over which the
   popup window appeared) will still fail to restore the Firefox menu.

   The only way to restore the Firefox menu is to make Firefox (once
   again) lose application focus and regain it -- for example by
   clicking on the Desktop and then on the browser window.

This is a fairly old regression:  The problem happens in the
2007-09-07-04-trunk Minefield nightly, but not in the
2007-09-06-04-trunk nightly.

There's no Cocoa widgets patch in that range.  But it does contain the
patch for bug 395122 ("Toolbar customization sheet is broken"), which
I currently think is most likely to have triggered this bug (if not to
have caused it).

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix

Here's a patch that fixes this bug -- by making sure the browser is
active before the Customize Toolbar popup can be used.

The patch for bug 395122 did trigger this bug -- because it changed
the Customize Toolbar object from a sheet to a popup window.

PopupWindow (native) objects are usually context menus, which can
legitimately be used while Firefox is in the background.  But this
isn't appropriate for a PopupWindow object that _isn't_ a context
menu.

A tryserver build will follow shortly.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Here's the tryserver build:

https://build.mozilla.org/tryserver-builds/2008-05-19_16:[e-mail]-bugzilla434097/[e-mail]

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Is it alright to land this now on mozilla-central (before it lands on
the 1.9.0 branch)?  That'd give it some time to bake there.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Landed on mozilla-central.

Comment 9

[Samuel Sidler (old account; do not CC)]

Let's get this in 1.9.0.3.

Comment 10

[Daniel Veditz [:dveditz]]

Not a blocker, if someone wants to champion the patch (and has a regression testcase) you can request approval.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

> has a regression testcase

What do you mean by this?

Comment 12

[Samuel Sidler (old account; do not CC)]

He means an automated testcase so we ensure this doesn't break in the future. Alternatively, but less preferred, a Litmus testcase.

A statement of risk would be good as well.