159277 - Hover on Secondary/Multi-Monitor doesn't work correctly

Status: VERIFIED DUPLICATE of bug 135079

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[David Lamparter]

When using multi monitoring, Mozilla doesn't display "hover" items correctly, it
starts "flickering". e.g. When the mouse is moved over a link, it displays the
link location in the status bar for about 0.2 s, then it returns to the normal
"Document: Transferred" as if the mouse wouldn't be over the link.

Info:
Found on: Mozilla 1.1beta, Mozilla 1.0rc2
Affects: Everything, even the Main Menu Bar
Conditions: Dual Monitoring / Multi Monitoring with a Screen placed left of the
Primary Screen (having negative X/Y Mouse Coordinates)
Reproducable: Yes
System: Windows XP Professional, Build 2600 German, AMD Athlon 1.1, 768 MB RAM,
ATI Radeon 7500, DirectX 8.1
Display Configuration: Primary 1024x768, 32bpp, at 0,0; Secondary 800x600,
32bpp, at -800,0
Note: On the Primary Screen everything works as it should

Guess: Maybe the Display Engine somewhere assumes that Mouse Coordinates can't
get negative ... but they can, with Multi Monitoring

David Lamparter, [e-mail]

[Please excuse my bad english, I'm from Germany]

Comment 1

[Matthias Versen [:Matti]]

-> Xp apps

Comment 2

[Boris Zbarsky [:bzbarsky]]

This has nothing to do with XP apps....

Comment 3

[Tim Fountain]

I have also experienced this bug on various machines with different builds of
Mozilla and completely different graphics card setups.  It's an inconvenience
when developing, as if you're trying to see where a link points to by moving the
mouse over it and looking at the status bar; the link disappears almost immediately.

Comment 4

[R.K.Aa.]

*** Bug 172461 has been marked as a duplicate of this bug. ***

Comment 5

[R.K.Aa.]

*** Bug 179620 has been marked as a duplicate of this bug. ***

Comment 6

[Merlyn]

*** Bug 166363 has been marked as a duplicate of this bug. ***

Comment 7

[R.K.Aa.]

*** Bug 179872 has been marked as a duplicate of this bug. ***

Comment 8

[R.K.Aa.]

Resembles bug 141599

Comment 9

[Thomas Fee]

Not sure what the original bug reporter meant in detail but I can add that the
color highlighting of a toolbar icon does not work correctly. The highlight
shows up as long as the mouse pointer is moving over the toolbar button/icon but
reverts back to unhighlighted as soon as the mouse pointer stops moving, even
though it is still pointing at the center of the icon.

This only occurs when the icon is displayed on the second (or secondary) monitor
on my two-monitor Windows XP system. Both videa cards are identical. Two icons
on the same toolbar of a single window (e.g. Composer) will display differently
if one icon is shown on one screen while the other icon is shown on the other
screen.

Comment 10

[Oliver Vettel]

I can confirm this bug on Windows XP, too. And this bug occurs on basically all
mouseover-effects in mozilla, including the GUI (Toolbars, Menus etc). 

When I drag mozilla onto the secondary screen (which is to the left, ie negative
coords), mouseovers start to "flicker", when I drag the window back to the
primary screen, they start working again.

Comment 11

[R.K.Aa.]

*** Bug 190008 has been marked as a duplicate of this bug. ***

Comment 12

[Boris Zbarsky [:bzbarsky]]

Hmm... This seems like an ESM-ish problem...

Comment 13

[Alex Dossey]

I would love to see this fixed.  This problem only occurs when the second
monitor is to the LEFT of the primary monitor, leading me to believe that this
is a negative coordinate problem.  I assume that mozilla doesn't support
negative coordinates correctly.  This has been a problem since the 1.0 release
(or maybe older, I just don't know).

Steps to reproduce:
1. On an XP (not sure if it's limited to XP or not) machine with two video
cards, set the primary monitor as the monitor on the right.
2. Drag Mozilla to the monitor on the left.
3. Hover the mouse over any item that changes when hovered over (menu items will
work)

Result:
The expected visual change when the item is hovered over appears, and then
disappears.  The visual change sustains as long as the mouse is moving over the
item.

Expected result:
The expected visual change to the hovered item should 'stick' as long as the
mouse is over the item.

Comment 14

[Duncan Lilly]

This is not just XP - it affects my Win2000 system as well.  I don't have a
multi-monitor 98 setup to test it on but I suspect it will be the same.

Comment 15

[Ricardo SIGNES]

Yeah, this bug is incredibly annoying, especially since some of our in-house
apps use hover-stuff extensively.  Another interesting fact:  if the Moz window
is split across the left and center displays (given three displays), hovering
that causes a tooltip will cause the tooltip to appear at the leftmost point on
the center display.

I can also confirm that this occurs only on monitors to the left of center.

Comment 16

[David Lamparter]

btw, this bug also happens when having positioned the secondary screen above the
primary screen (=> negative Y coordinates)

Comment 17

[Vedran Miletic]

*** Bug 211987 has been marked as a duplicate of this bug. ***

Comment 18

[Vedran Miletic]

*** Bug 211941 has been marked as a duplicate of this bug. ***

Comment 19

[Greg Sherman]

I am confirming this issue with my multi-monitor setup. 

There are other annoying side effects of this bug. When you click on the down
arrow in the address bar, the list of prior addresses appears on a different
monitor. 

To reproduce, you need to have mozilla opened on your second monitor, which
needs to be setup to the left of your primary monitor. 

Comment 20

[Matt Ginzton]

I think all these bugs are the same: bug 135079, bug 141599, bug 154163, bug
159277, bug 222817.  I'm putting this in all the bugs in the hopes one of the 5
different owners of these 5 different bugs will fix it and resolve the rest as
dupes; I don't know if I have permission to resolve/dupe myself and I don't know
which one is most likely to get attention first :)

Comment 21

[石庭豐 (Seak, Teng-Fong)]

Bug 75313 is one of the effects of this bug ==> need to add it to depend on this?

However, the summary of this bug needs some modifications.

For instance, it's not only about hover (which I think is restricted to DOM
event) but everything concerning mouse pointer.  All GUI elements, from menu to
toolbar, context menu to status bar.

OTOH, maybe we need to add some more keywords like dual monitor, multi-display
and dual-display.  Actually, when I used multi-display, I didn't find this bug
and thus I created a dup bug 228548.

Comment 22

[José Jeria]

*** Bug 222682 has been marked as a duplicate of this bug. ***

Comment 23

[José Jeria]

*** Bug 222817 has been marked as a duplicate of this bug. ***

Comment 24

[John Sullivan]

In case it's useful for resolving this, there are several ways of validating
screen coordinates under windows:

You can just assume (0,0) is the top-left and not impose an upper limit. This
doesn't work if the user has placed the taskbar on the left or top, since some
window positions will now be obscured by the taskbar. (Annoying if the taskbar
completely obscures the window titlebar, so you can't drag it out of the way.)
And it doesn't handle multiple monitors.

You can call ClientToScreen(GetClientRect(GetDesktopWindow())) or
GetSystemMetric(SM_CXSCREEN/SM_CYSCREEN). This allows an upper bound on
coordinates but has the same problems as above.

Before multiple monitors, the preferred way was to use
SystemParametersInfo(SPI_GETWORKAREA), which returns the usuable area of the
primary display. Gives good bounds on that display but doesn't handle multiple
displays.

Now (Win98 and later, Win2000 and later) there is
GetSystemMetrics(SM_XVIRTUALSCREEN), SM_YVIRTUALSCREEN, SM_CXVIRTUALSCREEN and
SM_CYVIRTUALSCREEN, which return the left, top, width and height of the full
desktop area, including multiple monitors. Left and top can be negative, and any
coordinate within these bounds is to be considered valid. (Well, there may be
subrectangles of that area which don't actually exist if your monitors are set
to different resolutions, but that's not a major problem.)

If you do want to go further, you can call EnumDisplayMonitors (again,
Win98/Win2000 and above only) and GetMonitorInfo which will tell you the virtual
desktop rectangle of each attached monitor. Valid screen coordinates lie within
the union of all these rectangles - if the monitors are set to different
resolutions this shape might not be rectangular. The documentation for these
functions specifically warns that some coordinate values may well be negative.

Comment 25

[Olivier Cahagne]

*** Bug 230666 has been marked as a duplicate of this bug. ***

Comment 26

[José Jeria]

Dupe of bug 135079.

Comment 27

[José Jeria]

If nobody object, i am going to dupe this to bug 135079, which is exactly what
this bug is about.



*** This bug has been marked as a duplicate of 135079 ***

Comment 28

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

verified.