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

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Tanner M. Young [:tmyoung]]

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

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Did this regress recently? This many dupes makes me suspect something's up!

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 5

[Tanner M. Young [:tmyoung]]

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.

Comment 6

[Tanner M. Young [:tmyoung]]

It is caused by that, because if you turn the Menu bar back on, the problem goes away.

Comment 7

[Tanner M. Young [:tmyoung]]

Also, this occurs if the user pushes the title bar above the edge of the screen, so it is not limited to window maximization.

Comment 8

[Jim Mathies [:jimm]]

I don't have a dual monitor setup to find this. Cinema displays work fine, fwiw.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 10

[Jim Mathies [:jimm]]

(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.

Comment 11

[Jim Mathies [:jimm]]

Bug 248552?

Comment 12

[Tanner M. Young [:tmyoung]]

(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."

Comment 13

[Jim Mathies [:jimm]]

Where does the drop down end up getting positioned on the main display?

Comment 14

[Jim Mathies [:jimm]]

For my reference:

http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsMenuPopupFrame.cpp#954

Comment 15

[Tanner M. Young [:tmyoung]]

Attachment: Search box positioning screenshot

Here is a screenshot.

Comment 17

[Salvador L. Balbon]

attaching 2 screenshots from duplicated bug 576183

Comment 18

[Salvador L. Balbon]

Attachment: dropdown menu going upwards (firefox window not maximized)

Comment 19

[Salvador L. Balbon]

Attachment: dropdown menu going upwards (firefox window maximized)

Comment 20

[Timothy Nikkel (:tnikkel)]

Comment on attachment 455403 [details]
dropdown menu going upwards (firefox window not maximized)

Screenshot is not for this bug.

Comment 21

[Paul [pwd]]

Is this not a dupe of bug 576665?

Comment 23

[Tanay Gavankar [:tgavankar]]

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.

Comment 29

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 30

[:Felipe Gomes (needinfo for replies!)]

Attachment: Open popup window on monitor with the biggest intersection from its anchor frame

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

Comment 31

[Timothy Nikkel (:tnikkel)]

(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?

Comment 32

[:Felipe Gomes (needinfo for replies!)]

Attachment: Open popup window on monitor with the biggest intersection from its anchor frame - v2

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.

Comment 33

[:Felipe Gomes (needinfo for replies!)]

(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 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 35

[Neil Deakin]

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.

Comment 36

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/101e02600e5b

Comment 41

[Aakash Desai [:aakashd]]

Users were reporting this via Input - http://input.mozilla.com/en-US/search/?product=firefox&sentiment=sad&date_end=&date_start=&version=&os=win7&q=dual+monitor+search

Comment 42

[Tanay Gavankar [:tgavankar]]

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.

Comment 44

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336