Closed
Bug 159277
Opened 22 years ago
Closed 20 years ago
Hover on Secondary/Multi-Monitor doesn't work correctly
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
VERIFIED
DUPLICATE
of bug 135079
People
(Reporter: david.lamparter, Assigned: saari)
References
Details
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, david.lamparter@t-online.de [Please excuse my bad english, I'm from Germany]
Comment 1•22 years ago
|
||
-> Xp apps
Assignee: Matti → sgehani
Component: Browser-General → XP Apps
QA Contact: asa → paw
Comment 2•22 years ago
|
||
This has nothing to do with XP apps....
Assignee: sgehani → attinasi
Component: XP Apps → Layout
QA Contact: paw → petersen
Updated•22 years ago
|
QA Contact: petersen → amar
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 3•22 years ago
|
||
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.
*** Bug 172461 has been marked as a duplicate of this bug. ***
*** Bug 179620 has been marked as a duplicate of this bug. ***
*** Bug 166363 has been marked as a duplicate of this bug. ***
*** Bug 179872 has been marked as a duplicate of this bug. ***
Resembles bug 141599
Comment 9•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
*** Bug 190008 has been marked as a duplicate of this bug. ***
Comment 12•21 years ago
|
||
Hmm... This seems like an ESM-ish problem...
Assignee: attinasi → saari
Component: Layout → Event Handling
Priority: P4 → --
QA Contact: amar → desale
Target Milestone: Future → ---
Comment 13•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Reporter | ||
Comment 16•21 years ago
|
||
btw, this bug also happens when having positioned the secondary screen above the primary screen (=> negative Y coordinates)
Comment 17•21 years ago
|
||
*** Bug 211987 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
*** Bug 211941 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
*** Bug 222682 has been marked as a duplicate of this bug. ***
Comment 23•21 years ago
|
||
*** Bug 222817 has been marked as a duplicate of this bug. ***
Comment 24•21 years ago
|
||
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•21 years ago
|
||
*** Bug 230666 has been marked as a duplicate of this bug. ***
Comment 26•21 years ago
|
||
Dupe of bug 135079.
Updated•20 years ago
|
Blocks: multimon-win
Comment 27•20 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
No longer blocks: multimon-win
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•