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.
See bug 788189, which may have the same regression range as this bug.
I still get this on a 09-17 build, whereas the bug 788189 has gone away.
We need a regression range for this (in mozilla-central nightlies).
Related to or dup of bug 792110?
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
Last good nightly: 2012-08-30 First bad nightly: 2012-08-31 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=706174d31a02&tochange=fcc533f691e9
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
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.
(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.
Created attachment 662718 [details] [diff] [review] 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 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?
nsView::SetVisibility calls nsView::NotifyEffectiveVisibilityChanged which calls DoResetWidgetBounds, so if nothing else does, that will.
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
Backed out from Aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/aee404ebbdae
But I also backed out bug 786421 on aurora, which caused this bug, so this should still be fixed on 18.
(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.
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.
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
mass remove verifyme requests greater than 4 months old