Closed Bug 130527 Opened 24 years ago Closed 21 years ago

When using dual screens, menus and highlighted items fail

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: tillsnot, Assigned: hyatt)

References

Details

Using a dual monitor setup, if any Mozilla windows, including mail and news are opened on the display designated as display 2. Items that highlight ie. Menu items, rollover graphics/links, buttons, are very spasmodic. Sometimes to the point they will not operate.
Please always include build ID in bug-reports. Sounds like a dup of bug 36550, but that one was fixed in April last year..
Reproduced with 20020304/WinNT.
Status: UNCONFIRMED → NEW
Ever confirmed: true
shouldn't this belong in XP Toolkit/Widgets: Menus? and is it related to bug 135079?
I have the same problem with Windows98 SE (Mozilla build 2002031104) and I wrote a quite long bug report. If it helps you, here it is: I have two different-sized screens on my system like this: ------------- | | ------------ | 1280x1024 | | 1024x768 | | | | | | secondary | | primary | | | ------------ ------------- So when I run mozilla fullscreen on the secondary screen all menus (File, Edit,...) open on the primary screen! Even worse, they open on the position (=y-coordinate) they should open on the secondary screen, that means they open "above" the primary screen and I can only see the lower part of the menu (if the menu is that large, I can't see e.g. the Search and Go menu at all). ------------------- | New Navi window | | New | | Open web loc | | Open file | | Close | | . | | . | | . | invisible area | . | | Print preview | ----------------------------- primary display top edge | Print | | | Work offline | | visible area | Exit | | ------------------- | | | primary display | | Also all drop-downs (for example the location bar history) appear, like the menus on the primary screen. Also the context menu (right-click) and the tooltips for the buttons (back, forward,...) and the personal toolbar folder have that kind of problem: they appear on the secondary screen but very far down (i guess they appear on the y-position they would appear on the primary screen if the mozilla would run there). But that's just a cosmetical thing. Ah yes, of course also the bookmarks on the personal bookmark folder open on the primary screen. If that info helps you: There are some other programs that have this problem too. For example Open Office (Build 641), whereas Staroffice 5.2 runs correctly. There are more programs, but I don' know any names. If that interests you you can ask in news://microsoft.public.win98.display.multi_monitor I hope that image helps you, if you need screenshots or some more testing mail me (adolf.schwarz@gmx.at).
Reproduced with Mozilla Release Candidate 2 on Windows XP Professional. Using a three-head setup; displays 1 and 3 are on an AGP Matrox Millennium G550, and display 2 is on a PCI NVIDIA RIVA TNT2. Set up like: 2 1 3 I noticed that if I move the Mozilla window so it's half on display 2 and half on display 1, that the menus that are on display 2 display the flickering, spasmodic behavior -- but the menus that are on display 1 act just fine. In fact, if I take a single menu (say, Bookmarks) and position the window so half of the word "Bookmarks" is on display 2 and half is on display 1, the half on display 2 is spasmodic and the half on display 1 is just fine. Is there any more data I can input to help debug this?
With 1.0 (2002053012), I see the same behavior in XP Pro. When on the second monitor, context menus seem to work OK, but regular menus (File | Edit or Bookmarks) open on monitor 1 on the right edge of the screen. It's as if there's some sanity code checking to ensure that the menu doesn't open outside of the *physical* screen X dimensions, when it needs to take into account *logical* X dimensions. In addition, context (right-click) menus open to the *left* of the mouse cursor instead of the *right* as on monitor 1. Again, it's like alignment code is looking at physical dimensions instead of logical ones in determining when to go to the left of the cursor. Unfortunately I'm not sure what everyone means when they say "spasmodic". The behavior I'm seeing is very specific and absolute, not intermittent. There may be additional symptoms or maybe my problem isn't really what this bug report is about.
.
Assignee: asa → hyatt
Component: Browser-General → XP Toolkit/Widgets: Menus
QA Contact: doron → shrir
See this on Mac (Powerbook G4/800 DVI running OS X 10.1.5) too. Please change to all platform/os. Thanks. Max.
I confirm the behavior on multiple screens. This with Mozilla 1.1b. When the window resides on the second (third, fourth, etc) display, items are highlighted (buttons in toolbars, menu headings and items) only when the mouse is in motion over said object. Exception is submenu headings, which while the sub-menu is displayed are highlighted. I've tried with multiple themes, and all exhibit the same behavior. Everything works properly when the window resides on the primary display. The problem is not limited to the browser. Mail and News also exhibits the same behavior.
I have seen behavior described in comment #5 on my setup which is 2 1 on Windows 2000 SP3 with mozilla 1.1b. But I haven't seen what is described in comment #4. And I would add that sub menus are also affected and lose the highlight if the mouse stops moving. Also sub menus are not activated by hovering when on the secondary screen. So, Click on File menu ---->Move mouse to hover over the "New" menu item Now on the primary display the "New" menu item will be highlighted and after a small delay the "New" submenu will be displayed. On the secondary screen the "New " menu item loses the highlight and the sub menu is not displayed until the user clicks on the "New" menu item.
I think this may have a similar cause as bug #36550 Window unresponsive if in negative coord-space [such as in Dual Monitor setup]. The cause of that was a problem with negative space coordinates that is the anything to the top and left of the primary screen.
Behaviour still there in build 20020826 (mozilla 1.0.1) on Windows 2000.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Don't know if I should have filed a new bug, but this problem still exists and now I've noticed title tips don't show on the secondary display. As is mentioned in comment 9, the problems is that nothing works unless the mouse is in motion...
I can no longer reproduce the _original_ quirky behavior I was seeing (comment #6) in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130, though one last (trivial) quirk remains: If I have my Mozilla window stradling both monitors, with the entire menu on monitor 1 but the right half of the window (starting maybe 100 pixels to the right of Help) on monitor 2, the File menu pops up on monitor 2. If I move the window a little to the left, so that more of the window is present on monitor 1, the File menu opens on monitor 1 as expected. I expect to see the File menu opening on monitor 1 so long as the text "File" appears on monitor 1 (especially if I'm clicking on monitor 1). Other than that, each menu opens exactly where I expect it to open.
Problem symptoms (as described in comments 9 & 13) still exist in Mozilla 1.6. [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113]
Anyone else notice that this bug appears to have been fixed in v1.7! This may well possibly fix bug 141599 as well (arguably a duplicate of this bug). Thanks to whoever is responsible!
This bug should have been linked to META bug 236647.
Blocks: multimon-win
Also WFM, marking as such If anyone can reproduce this bug with a nightly build, please reopen.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.