Last Comment Bug 789482 - Awesome bar suggestions briefly appear on wrong monitor with multiple monitors
: Awesome bar suggestions briefly appear on wrong monitor with multiple monitors
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: mozilla18
Assigned To: Timothy Nikkel (:tnikkel)
: Markus Stange [:mstange]
: 792110 (view as bug list)
Depends on: 803518 837433
Blocks: 786421
  Show dependency treegraph
Reported: 2012-09-07 08:36 PDT by Andrew McCreight [:mccr8]
Modified: 2014-01-10 10:41 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (1.24 KB, patch)
2012-09-19 15:28 PDT, Timothy Nikkel (:tnikkel)
roc: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Andrew McCreight [:mccr8] 2012-09-07 08:36:53 PDT
I have two monitors, and I'm running Firefox on the secondary monitor. Under some circumstances, the Awesomebar suggestions briefly flash on the primary monitor before being displayed on the secondary monitor.

Steps to reproduce:
1. Click on the "open a new tab" button.
2. Focus is now on the awesome bar. Hit 't', which for me brings up the suggestion of This causes the first flash of the suggestions on the primary monitor. Sometimes this doesn't cause the flash.
3. Hit 'w'. No flash.
4. Click on the down triangle in the awesome bar. Note that the list of suggestions is already being displayed. This also causes the flash of the suggestion on the primary monitor. This seems to reproduce fairly consistently for me.

I think this started showing up at some point during the last week or so.

I'm filing this in Widget:Cocoa because these weird multi-monitor problems I have seem to end up here. I'm on 10.6.
Comment 1 Steven Michaud [:smichaud] (Retired) 2012-09-07 09:22:43 PDT
See bug 788189, which may have the same regression range as this bug.
Comment 2 Andrew McCreight [:mccr8] 2012-09-17 14:24:45 PDT
I still get this on a 09-17 build, whereas the bug 788189 has gone away.
Comment 3 Steven Michaud [:smichaud] (Retired) 2012-09-17 14:28:21 PDT
We need a regression range for this (in mozilla-central nightlies).
Comment 4 Steven Michaud [:smichaud] (Retired) 2012-09-18 10:49:43 PDT
Related to or dup of bug 792110?
Comment 5 Benoit Girard (:BenWa) 2012-09-18 11:17:43 PDT
*** Bug 792110 has been marked as a duplicate of this bug. ***
Comment 6 Benoit Girard (:BenWa) 2012-09-18 11:18:22 PDT
I filed my list of STR with a video in
Comment 7 Benoit Girard (:BenWa) 2012-09-18 14:58:04 PDT
Last good nightly: 2012-08-30
First bad nightly: 2012-08-31

Comment 8 Benoit Girard (:BenWa) 2012-09-18 15:58:08 PDT
I narrowed it down but I'm done for the day. It would be lovely if someone has time to continue:
Comment 9 Steven Michaud [:smichaud] (Retired) 2012-09-18 16:32:24 PDT
I'd guess

But even if I'm right, I don't think that can be the cause of this bug -- just the trigger.
Comment 10 Andrew McCreight [:mccr8] 2012-09-18 16:59:59 PDT
(In reply to Steven Michaud from comment #9)
> I'd guess
> But even if I'm right, I don't think that can be the cause of this bug --
> just the trigger.

Seems like you were right.  I undid just that change in a local build and I wasn't able to reproduce the problem any more.
Comment 11 Timothy Nikkel (:tnikkel) 2012-09-19 15:28:14 PDT
Created attachment 662718 [details] [diff] [review]

In CalcWidgetBounds for popup widgets we add the screen offset for the parent widget in the popup widgets coords, but only if the view is visible. So if the view is hidden and we update the size/position of the widget we will get wrong coords.

We used to size all hidden popups to 0,0, so this code should be equivalent to what we used to do.
Comment 12 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-09-19 16:22:15 PDT
Comment on attachment 662718 [details] [diff] [review]

Review of attachment 662718 [details] [diff] [review]:

When the widget becomes visible, are we going to reset the bounds?
Comment 13 Timothy Nikkel (:tnikkel) 2012-09-19 16:28:04 PDT
nsView::SetVisibility calls nsView::NotifyEffectiveVisibilityChanged which calls DoResetWidgetBounds, so if nothing else does, that will.
Comment 14 Timothy Nikkel (:tnikkel) 2012-09-19 20:14:09 PDT
Comment 15 :Ms2ger (⌚ UTC+1/+2) 2012-09-20 04:48:41 PDT
Comment 16 Timothy Nikkel (:tnikkel) 2012-09-24 12:13:47 PDT
Comment on attachment 662718 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 786421
User impact if declined: some popups like the awesome bar dropdown will flash on the wrong screen in multi-monitor situations
Testing completed (on m-c, etc.): several days on nightlies
Risk to taking this patch (and alternatives if risky): should be pretty safe, it reinstates our old behaviour
String or UUID changes made by this patch: none
Comment 17 Timothy Nikkel (:tnikkel) 2012-09-24 18:28:24 PDT
Comment 18 Scoobidiver (away) 2012-11-03 03:53:35 PDT
Backed out from Aurora:
Comment 19 Timothy Nikkel (:tnikkel) 2012-11-03 10:07:59 PDT
But I also backed out bug 786421 on aurora, which caused this bug, so this should still be fixed on 18.
Comment 20 Scoobidiver (away) 2012-11-03 12:40:45 PDT
(In reply to Timothy Nikkel (:tn) from comment #19)
> But I also backed out bug 786421 on aurora, which caused this bug, so this
> should still be fixed on 18.
There have been no backout of bug 786421 on Aurora 18.
Comment 21 Timothy Nikkel (:tnikkel) 2012-11-03 13:28:01 PDT backs out bug 786421 and fixes it in a different way in one changeset, although the commit message doesn't make that clear.
Comment 22 Timothy Nikkel (:tnikkel) 2012-11-06 14:40:30 PST
backed out of beta for the same reason (but this bug should still be fixed on beta)
Comment 23 Tracy Walker [:tracy] 2014-01-10 10:41:06 PST
mass remove verifyme requests greater than 4 months old

Note You need to log in before you can comment on or make changes to this bug.