Closed Bug 575328 Opened 14 years ago Closed 14 years ago

Search suggestions box appears on wrong monitor in multiple monitor environment when window is maximized

Categories

(Core :: XUL, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla2.0b3
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: mozilla.bugs, Assigned: Felipe)

References

Details

(Keywords: regression, Whiteboard: [4b1] [Input])

Attachments

(2 files, 3 obsolete files)

If Firefox is maximized and open on a secondary monitor in a multiple monitor environment, when running a Google search in the search box, the suggestions are show on the main monitor.

1. Open Firefox in a multiple monitor environment
2. Maximize window
3. Set search engine to Google
4. Start typing search

A simple workaround for the moment is having the window not be maximized, but this should be fixed regardless.

Mozilla/5.0 (Windows; U; Windows NT 6.0; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100628 Minefield/3.7a6pre ID:20100628035917
Summary: Search suggestions box appears on wrong monitor in multiple monitor environment → Search suggestions box appears on wrong monitor in multiple monitor environment when window is maximized
Component: Search → XP Toolkit/Widgets: XUL
Product: Firefox → Core
QA Contact: search → xptoolkit.xul
Whiteboard: DUPEME
Did this regress recently? This many dupes makes me suspect something's up!
I cannot reproduce it on OS X. Eventually it could be a regression for Windows only. Anyone also sees this behavior with Firefox 3.6.6? Or is it only present for 4.0b builds?
I believe this was caused by the drawing in the title bar changes in Bug 513162.  It didn't do it before that, but I haven't properly tested that regression window to make totally sure.
Keywords: regression
It is caused by that, because if you turn the Menu bar back on, the problem goes away.
Blocks: 513162
blocking2.0: --- → ?
Whiteboard: DUPEME → [4b1]
Also, this occurs if the user pushes the title bar above the edge of the screen, so it is not limited to window maximization.
I don't have a dual monitor setup to find this. Cinema displays work fine, fwiw.
(In reply to comment #7)
> Also, this occurs if the user pushes the title bar above the edge of the
> screen, so it is not limited to window maximization.

This is another issue which is kinda old. I can't find the bug right now. So please limit testing for window maximization.
(In reply to comment #9)
> (In reply to comment #7)
> > Also, this occurs if the user pushes the title bar above the edge of the
> > screen, so it is not limited to window maximization.
> 
> This is another issue which is kinda old. I can't find the bug right now. So
> please limit testing for window maximization.

Technically the client area of the window is above the screen bounds when maximized, so these are probably the same bugs.
Blocks: multimon-win
(In reply to comment #11)
> Bug 248552?

It's not.

(In reply to comment #9)
> This is another issue which is kinda old. I can't find the bug right now. So
> please limit testing for window maximization.

The problem when moving the browser above the screen area goes away when you turn off the new title bar, so the two cases are the same issue.  This just offers another way to test the bug, and it shows that this is somehow related to a bounding issue.

My guess would be that when the title bar starts to go off of the screen something is triggered that assumes that "since we are out of the screen boundaries, we are on the main monitor."
Where does the drop down end up getting positioned on the main display?
Here is a screenshot.
attaching 2 screenshots from duplicated bug 576183
Comment on attachment 455403 [details]
dropdown menu going upwards (firefox window not maximized)

Screenshot is not for this bug.
Attachment #455403 - Attachment is obsolete: true
Attachment #455404 - Attachment is obsolete: true
Is this not a dupe of bug 576665?
Bug 576665 was regarding the awesomebar's suggestions (as well as Google search's suggestions) appearing on the wrong monitor. 

The awesomebar bug occurs in 3.6.6 as well.
blocking2.0: ? → betaN+
Assignee: nobody → jmathies
Taking, I see what's going on here. This is actually a long standing bug with multimonitor popups (same cause as bug 576665, and it affects 3.6) but is easier triggered now with the new titlebar. A lot of cases were fixed by bug 393186 but this one still happens.
Assignee: jmathies → felipc
Status: NEW → ASSIGNED
(Asking review from Roc, since I think you reviewed other similar fixes)

Summary of the fix:

when determining the screen of a popup window, nsMenuPopupFrame::SetPopupPosition calls GetConstrainedRect. However, GetConstrainedRect was only taking into account the TopLeft position of the anchor frame, while it could consider the whole rect. 

The search-bar dropdown is anchored at the root element, and when Firefox is: a) using the new titlebar, and b) maximized, its top-left edge falls off-screen, so the wrong monitor was picked.

The fix is straightforward since nsIScreenManager::ScreenForRect is already capable of considering the biggest intersecting rect instead of just a point. It was almost a waste not to use that info!

(while I were at it I converted the second nsRect& paremeter to const nsRect&)
Attachment #460401 - Flags: review?(roc)
(In reply to comment #30)
> The search-bar dropdown is anchored at the root element, and when Firefox is:
> a) using the new titlebar, and b) maximized, its top-left edge falls
> off-screen, so the wrong monitor was picked.

That sounds odd. How far does it go off-screen?
Extra change, it appears that sometimes the anchor frames are 0x0 sized, and ScreenForRect would give back the primary monitor in that case. If that's the case we use a 1x1 rect as was used before.
Attachment #460401 - Attachment is obsolete: true
Attachment #460436 - Flags: review?(roc)
Attachment #460401 - Flags: review?(roc)
(In reply to comment #31)
> (In reply to comment #30)
> > The search-bar dropdown is anchored at the root element, and when Firefox is:
> > a) using the new titlebar, and b) maximized, its top-left edge falls
> > off-screen, so the wrong monitor was picked.
> 
> That sounds odd. How far does it go off-screen?

I think it goes -8x-8, due to IIRC a quirk in Windows that needs to have the original window border sizes considered even on maximized state for proper handling of the close/maximize buttons.
Comment on attachment 460436 [details] [diff] [review]
Open popup window on monitor with the biggest intersection from its anchor frame - v2

Neil Deakin is the right reviewer here.
Attachment #460436 - Flags: review?(roc) → review?(enndeakin)
Comment on attachment 460436 [details] [diff] [review]
Open popup window on monitor with the biggest intersection from its anchor frame - v2

This looks ok. Technically, there will be cases where it would be more correct to use the corner the popup is anchored to, but that's a big edge case that doesn't matter too much.
Attachment #460436 - Flags: review?(enndeakin) → review+
http://hg.mozilla.org/mozilla-central/rev/101e02600e5b
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Target Milestone: --- → mozilla2.0b3
Awesomebar seems to be appearing on correct monitor for win7. VERI FIXED

I opened a followup bug because behavior is still exhibited by the search bar,
bug 592107.
Status: RESOLVED → VERIFIED
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
See Also: → 1564949
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: