Awesome bar suggestions briefly appear on wrong monitor with multiple monitors

RESOLVED FIXED in Firefox 17

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: mccr8, Assigned: tnikkel)

Tracking

unspecified
mozilla18
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox17+ fixed, firefox18+ fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 2

5 years ago
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).
Keywords: regressionwindow-wanted
Related to or dup of bug 792110?

Updated

5 years ago
Duplicate of this 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
Keywords: regressionwindow-wanted
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.
(Reporter)

Comment 10

5 years ago
(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.
(Assignee)

Updated

5 years ago
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
(Assignee)

Updated

5 years ago
Blocks: 786421
(Assignee)

Comment 11

5 years ago
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.
Assignee: nobody → tnikkel
Attachment #662718 - Flags: review?(roc)
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?
(Assignee)

Comment 13

5 years ago
nsView::SetVisibility calls nsView::NotifyEffectiveVisibilityChanged which calls DoResetWidgetBounds, so if nothing else does, that will.
Attachment #662718 - Flags: review?(roc) → review+
(Assignee)

Comment 14

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/2657b58d787c
https://hg.mozilla.org/mozilla-central/rev/2657b58d787c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18

Updated

5 years ago
status-firefox18: --- → fixed
tracking-firefox17: ? → +
tracking-firefox18: ? → +
(Assignee)

Comment 16

5 years ago
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
Attachment #662718 - Flags: approval-mozilla-aurora?
Attachment #662718 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 17

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/67fb90cf273e
status-firefox17: --- → fixed
Keywords: verifyme

Updated

5 years ago
Depends on: 803518

Comment 18

5 years ago
Backed out from Aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/aee404ebbdae
status-firefox18: fixed → affected
(Assignee)

Comment 19

5 years ago
But I also backed out bug 786421 on aurora, which caused this bug, so this should still be fixed on 18.
status-firefox18: affected → fixed

Comment 20

5 years ago
(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.
status-firefox18: fixed → affected
(Assignee)

Comment 21

5 years ago
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.
status-firefox18: affected → fixed
(Assignee)

Comment 22

5 years ago
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

Updated

5 years ago
Depends on: 837433
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.