789482 - Awesome bar suggestions briefly appear on wrong monitor with multiple monitors

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Andrew McCreight [:mccr8]]

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 Twitter.com. 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)]

See bug 788189, which may have the same regression range as this bug.

Comment 2

[Andrew McCreight [:mccr8]]

I still get this on a 09-17 build, whereas the bug 788189 has gone away.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

We need a regression range for this (in mozilla-central nightlies).

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Related to or dup of bug 792110?

Comment 6

[Benoit Girard (:BenWa)]

I filed my list of STR with a video in https://bugzilla.mozilla.org/show_bug.cgi?id=792110#c0

https://dl.dropbox.com/u/10523664/Screenshots/bugzilla-awesomebar.mp4

Comment 7

[Benoit Girard (:BenWa)]

Last good nightly: 2012-08-30
First bad nightly: 2012-08-31

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=706174d31a02&tochange=fcc533f691e9

Comment 8

[Benoit Girard (:BenWa)]

I narrowed it down but I'm done for the day. It would be lovely if someone has time to continue:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=20a41ae07b49&tochange=d04edff1ae41

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I'd guess https://hg.mozilla.org/integration/mozilla-inbound/rev/e0ceffe737dd.

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

(In reply to Steven Michaud from comment #9)
> I'd guess
> https://hg.mozilla.org/integration/mozilla-inbound/rev/e0ceffe737dd.
> 
> 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)]

Attachment: patch

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

Comment on attachment 662718 [details] [diff] [review]
patch

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

When the widget becomes visible, are we going to reset the bounds?

Comment 13

[Timothy Nikkel (:tnikkel)]

nsView::SetVisibility calls nsView::NotifyEffectiveVisibilityChanged which calls DoResetWidgetBounds, so if nothing else does, that will.

Comment 14

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2657b58d787c

Comment 15

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/2657b58d787c

Comment 16

[Timothy Nikkel (:tnikkel)]

Comment on attachment 662718 [details] [diff] [review]
patch

[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)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/67fb90cf273e

Comment 18

[Scoobidiver (away)]

Backed out from Aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/aee404ebbdae

Comment 19

[Timothy Nikkel (:tnikkel)]

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

(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)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/dd53d0988e6f 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)]

backed out of beta for the same reason (but this bug should still be fixed on beta)
https://hg.mozilla.org/releases/mozilla-beta/rev/a1a77ade717f

Comment 23

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old