Open Bug 967096 Opened 11 years ago Updated 1 year ago

Various popup UI elements (tooltips, panels) appear in the wrong (primary?) monitor

Categories

(Core :: Widget: Win32, defect, P3)

Product:
Core
Component:
Widget: Win32
Version:
29 Branch
Type:
defect

Tracking

()

People

(Reporter: codacodercodacoder, Unassigned)

References

Details

(Keywords: multi-monitors, Whiteboard: [win:multimonitors][win:sizing])

Attachments

(10 files)

screenshot
(deleted), image/png
codacodercodacoder
: feedback+
Details
967096-2.png
(deleted), image/png
Details
967096-3.png
(deleted), image/png
Details
about-support.txt
(deleted), text/plain
Details
Screenshot 2021-01-28 100554.png
(deleted), image/png
Details
Screenshot 2021-01-28 100315.png
(deleted), image/png
Details
split screen example.jpg
(deleted), image/jpeg
Details
image.png
(deleted), image/png
Details
image.png
(deleted), image/png
Details
Screenshot 2022-10-17 132419.png
(deleted), image/png
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: Bug 1 - Highlight a term in the debugger Bug 2 - In the toolbar, hover over Settings cog/Console/Inspector buttons Actual results: Bug 1 - The popup appeared on the wrong monitor screen Bug 2 - The tooltip appears on the wrong monitor screen Expected results: When DevTools is open on monitor 1, 2, ... N, (and certainly when maximized), all UI elements should appear on the same monitor screen (discounting the possibility that the user is floating the window between monitors). Either way, UI elements should be "local" to the devtools UI. I suspect the code is mistakenly always targeting the primary display.
Component: Untriaged → Developer Tools: Debugger
So if I understand correctly, the tooltips from the toolbox tab bar or the debugger always appear on the first/primary monitor, correct? This sounds like a platform bug related to panels, not specific to devtools.
Summary: DevTools debugger is calculating screen coordinates incorrectly → Tooltips always appear in the primary monitor
No, only those mentioned. Far worse is "bug 1". My original title was better.
Summary: Tooltips always appear in the primary monitor → Various popup UI elements appear in the wrong (primary?) monitor
UI bits affected (tested in FF30) : - Debugger context menu (select some code to watch, right click, menu appears on wrong monitor) - Hover over variables, new "info popup" pops up on wrong monitor
And another affected ui component: - Inspector, Search HTML box, type in "d", menu pops up correctly offering "div", add an "i" to give "di" and menu shoots across to primary monitor located at top left of display.
I am on Windows 7 and all the UI elements listed above work perfectly fine on a 2 monitor setup (laptop + external screen) for me on latest Nightly and Aurora.
Try a three monitor setup?
I don't have one. Can you paste a screenshot of the issue btw ? properly explaining all three monitor's properties alongside ?
Moz should have a dev with a reasonably good/identical monitor setup investigate this. No part of the browser UI does this - it's only DevTools when launched separated from the browser window. Here's how my setup looks: +----------+ +----------+ +----------+ | | | | | | | mon 1 | | mon 2 | | mon 3 | | | | primary | | devtools | | | | | | | +----------+ +----------+ +----------+ Tools are maximized. Some popups appear so far off that their left border + approx 20 pixels appear on mon 1 (!) Hardware: Dell XPS 8300, unmodified mon1: whatever comes with the above mon2: Acer S230HL mon3: Acer S230HL And Nightly/Aurora are still doing it. It's like watching tennis. If this isn't fixed soon, I'll be suing Moz for whiplash ;)
Attached image screenshot (deleted) —
Attachment #8384534 - Flags: feedback+
The popup in the image is jammed between mon1 and 2.
We need someone with a 3-monitor setup to verify this. My guess is that it's a platform (XUL panel), not a devtools bug though.
Wherever it is in the code, the calculation that computes the eventual "landing" point is in error. I say that because, the popup pops up in the devtools UI then moves (animates, flies, very quickly) across the displays. When I joked about tennis, I wasn't... uh, you know, kidding ;)
can we get someone with a multi monitor setup on windows to test this? Most of our devs are on laptops maybe with one external monitor.
Keywords: qawanted
I concur with Rob (obviously) and would add the following: rant IMO, this whole popup thing is degrading the usefulness of the debugger in (too many) different ways: 1 - it's now a difficult and error prone task to scrape over a term in the debugger to then right-click and add it to the watch list - the color choices made (I'm on the Light Theme) clash badly - pale-blue "current-line" (which is not the current-line being executed, btw) clashes with... - everso-slightly different pale-blue mouse selection color - jumping around pale-green predictive selector - the selective region is cluttered by the tools' predictive pale-green selection which, as it happens, has never yet been what I want to select anyway. This has BROKEN age-old mousing behavior. - the "helpful" popup pops up, sometimes over what I'm doing, flies off to another monitor distracting me and removing any selection I've made (sometimes). - as a result of the above, by the time I come to right-click, 50% of the time my selection has completely disappeared. BAD. - similarly, I don't notice the selection has disappeared because the color choices are so bad, I perform a useless "Selection to Watch Expression" and find I'm staring at an empty "Add watch expression" input. BADDER. 2 - If I click on a term in the debugger, NOTHING HAPPENS. GOOD. - Clicking is a clear and positive indication of intent - Yet, If I mouseover a term, INTENTIONALLY or NOT, something pops up electing to tell me all sorts of stuff I may or, MORE LIKELY, have absolutely no interest in knowing. BADDER STILL. 3 - If I hover over something in the Variables/watch list, NOTHING HAPPENS. It seems clear to me that, whoever coded #2, had a notion that they "knew" what my intent was and attempted to get ahead of me. Sorry, you're wrong. And whoever didn't apply that thinking to the watch pane, had it right. Just because you can do something, doesn't mean you should. If it's unwanted it's clutter, noise, spam, junk mail... you get the idea? If I'm reviewing code in the source pane I'm most likely thinking about the logic, not the content of every var/array/object I happen to rest my mouse over. Thank heavens the tools don't have eye-tracking... jeez, can you imagine??? /rant
This is a platform bug.
Component: Developer Tools: Debugger → Widget
Product: Firefox → Core
Sorry,Nick, can you expand on that? What does that mean exactly?
(In reply to Russ from comment #16) > Sorry,Nick, can you expand on that? What does that mean exactly? This is a bug with XUL panels (part of the platform), not devtools code.
ah, got it. Which explains why, in the inspector, mousing around, the popup info-bar thing that appears over the browser window NEVER gets the monitor wrong. Right?
Add console popups (eg suggestions) to the affected UI components.
(In reply to Rob Campbell [:rc] (:robcee) from comment #13) > can we get someone with a multi monitor setup on windows to test this? Most > of our devs are on laptops maybe with one external monitor. I don't have the necessary hardware. Perhaps someone from US can help.
Flags: needinfo?(anthony.s.hughes)
Attached image 967096-2.png (deleted) —
You actually don't need an extra monitor. Latest Nightlies have been doing this on primary alone. See attachment.
I can't reproduce that both on primary/second monitor, nightly 31.0a1(2014-03-26), Win 7 x64.
Well, the image doesn't lie. Biggest clue is in comment 12: what is it that kicks in VERY soon after the popup is initially displayed? It's that code that animates the popup (XUL panel as Nick pointed out) and sends it to screen coords ~ 0, 0. And in these circumstances (where the bug is not seen elsewhere) I guess you'd look to weird hardware - this is standard off the shelf kit. Finally, Nothing else does this, AFAICT, only the FF devtools code. Needless to say, IE and Chrome popups work fine. If you want me to create an animated gif image of what I see here, let me know.
I'm not able to reproduce this either. It may be something with your set up that triggers this Firefox bug. Russ, can you do some testing to see if there are other XUL panels that reproduce this bug (ie. something outside of devtools)? Also if there is some more information you can tell us about your particular set up we may be able to replicate this.
Flags: needinfo?(anthony.s.hughes)
Keywords: qawanted
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #24) > I'm not able to reproduce this either. It may be something with your set up > that triggers this Firefox bug. Russ, can you do some testing to see if > there are other XUL panels that reproduce this bug (ie. something outside of > devtools)? Sure. But what exactly? > Also if there is some more information you can tell us about your > particular set up we may be able to replicate this. Like? Did you read from the top? I'm very willing to help but I (frankly) don't have time to guess at what you may or may not want to know. Ask me the question and I'll do my best to answer. Even so, I will ask a coworker (completely diff setup) to try this.
Sorry, I missed your comment 8. I'll see if we can closely replicate this in the QA lab. Juan, can you give this a try when you get a chance?
Flags: needinfo?(jbecerra)
*bump*, would be good to get try to repro here.
I was able to recreate the three-monitor setup by inserting a second graphics card in one of the machines in the lab. I have been trying to reproduce the two problems described in comment #0, but I have not been able to reproduce them. However, the machine in question has Windows 8 on it, and tomorrow I'll install Windows 7 and give it another try.
Flags: needinfo?(jbecerra)
Thanks for the update, Juan!
I installed Win7 on the machine in question and I have been trying to reproduce the problem, but so far all the popups I have been able to trigger appear in the same monitor as the one where the devtools is located. I had a setup similar as in comment #8. I'm not sure if I am doing this correctly, though. I asked one of our web devs to help me trigger this, and so far no luck. Russ, is there anyway you could attach a sample file I could then try this out with?
> Russ, is there anyway you could attach a sample file I could then try this > out with? Sure. Refer to the image 967096-3.png Seems to have improved somewhat - the popup is now much closer to the tools but still on the wrong monitor. DevTools is maximized on Monitor 3, Nightly running on monitor 2 (primary for me). If I restore (ie unmaximze) the tools, the popup works fine. Here's the code: <!DOCTYPE html> <html> <head> <title>test</title> <script> function key(ev) { debugger; if(ev.which === 13) { location = "http://www.google.com"; } } </script> </head> <body onkeypress="key(event)"> test </body> </html>
Attached image 967096-3.png (deleted) —
Something's changed. I've tried over and over and I CANNOT repro 967096-2.png. Somebody somewhere knows what's changed... Now it seems the only parts that are broken are the variable info popups and the tooltips for settings gear, Console and Inspector (from Debugger on to Network they work fine).
The widget team fixed some autocomplete popup positioning problems for us which may have fixed your initial bug. Looks like there's still a couple of things left to fix.
Summary: Various popup UI elements appear in the wrong (primary?) monitor → Various popup UI elements (tooltips, panels) appear in the wrong (primary?) monitor
Whiteboard: [see comment #32]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks Rob... (In reply to Rob Campbell [:rc] (:robcee) from comment #34) > The widget team fixed some autocomplete popup positioning problems for us > which may have fixed your initial bug. Looks like there's still a couple of > things left to fix. Thought so :) I'm seeing some other oddities (for example, the same info popup on second or subsequent invokation reduce its width by ~50%). Hard to repor though. :/ I've sent you an email re a meeting.
Attached file about-support.txt (deleted) —
Juan, as requested.
Someone else experienced this issue on Windows. See https://twitter.com/jonathansampson/status/472268510987419649 and http://i.imgur.com/wEc4p3a.gif Setup: widows, 2 monitors, browser on monitor 2, docked devtools, zoomed devtools font. Right-clicking in the inspector makes the popup appear on the other monitor.
I probably don't need to mention that the new event popup keyed on "ev" in the Inspector that now supports jQuery wrapped events is affected by this bug. Scroll bar sometimes doesn't appear and the whole popup is way too low down the screen. Worse still, the color picker - completely unusable since it appears a 80% *off* screen to the right of my right-most monitor. Useless.
(In reply to Russ from comment #39) > I probably don't need to mention that the new event popup keyed on "ev" in > the Inspector that now supports jQuery wrapped events is affected by this > bug. Scroll bar sometimes doesn't appear and the whole popup is way too low > down the screen. And now it's even worse (current Nightly) - popup is so far off to the right I can't even click the scrollbar thumb. Will #fx10 answer my prayers? Am I naive for even asking? (Don't answer that) :/
Flags: firefox-backlog?
OS: Windows 7 → All
Hardware: x86_64 → All
Component: Widget → Widget: Win32
Priority: -- → P1
Whiteboard: [see comment #32] → [see comment #32], tpi:+

Moving to p2 because no activity for at least 24 weeks.
See How Do You Triage for more information

Priority: P1 → P2
Priority: P2 → P1
Keywords: multi-monitors
Priority: P1 → P3
Whiteboard: [see comment #32], tpi:+ → [see comment #32], widget-next

I'm on Linux and my nightly usually puts all tooltips, popups etc on the first (left, builtin) monitor too.

Hello,

I have tried to reproduce this issue with 86.0b2(20210126185730) and 87.0a1(20210127213646) on the following configurations:

  • MacBook Pro A1278 laptop,macOS 10.15.6, attached to a Samsung S22B300 as well as a Samsung U28D590D monitor with an HDMI-DP adaptor
  • Asus ROG GL703VM laptop,Win10x64, attached to a Samsung S22B300 as well as a Samsung U28D590D via HDMI
  • Asus ROG GL703VM laptop,Ubuntu 20.04, attached to a Samsung S22B300 as well as a Samsung U28D590D via HDMI
    and did not manage to reproduce it.

@Codacore , are you still able to reproduce this issue with the mentioned STR and affected device?

Flags: needinfo?(codacodercodacoder)

I don't own the same hardware any longer. However, over successive hardware changes, the same or similar problems persist (for 7 years? That's crazy).

  1. Try stretching Firefox across 1+N monitor screens.
  2. Then open Options.
  3. Try any dropdown.

See attachments.

Flags: needinfo?(codacodercodacoder)
Attached image Screenshot 2021-01-28 100554.png (deleted) —
Attached image Screenshot 2021-01-28 100315.png (deleted) —

Here's the issue as I see it, and I'm not convinced this is something we need to prioritize.

STR:

  1. open Firefox on one monitor (in my case, 150% scaling, hidpi display), and open Options
  2. Drag firefox to a second monitor (100%, HD display)

If you drag the window far enough, Windows will trigger a DPI changed event and Firefox will re-scale to match the monitor you are moving to. After the scale event Firefox is scaled for the new monitor, even if some of the window still resides on the previous monitor. Similarly, if you don't drag the window far enough, scaling will remain set to that of the first monitor.

This is where we see some wonkiness with popup windows. For example, see attached screen grab, the blue line represents where the monitor boundaries reside. In this case, a popup associated with a drop down in Options will display on the monitor and scale according to the scaling Firefox is currently leveraging based on where it has been positioned.

All in all this is an outlier case IMHO.

Attached image split screen example.jpg (deleted) —
Flags: firefox-backlog?
Whiteboard: [see comment #32], widget-next

Hey, I reproduced one aspect of this and it didn't seem that serious. Can you provide STR of the issue you are seeing that you feel is serious? Thanks!

Flags: needinfo?(codacodercodacoder)
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1643644

Sorry for the tardy response.

Can you provide STR of the issue you are seeing that you feel is serious?

We're only dealing with serious bugs now? Gee, where's the emoji for a blank face with blinking eyes.

I think the screenshots make clear enough what the steps are. But, if you insist...

  1. Use more than one monitor.
  2. Spread Firefox (any version you like) across the monitors.
  3. Open (for example) Settings
  4. Click ANY dropdown (HTML select element)
  5. Stand back and say, "Hmm, that's not serious"

Alt:

  1. Bring up (float) devtools console.
  2. type "doc"
  3. See #5 above.

But, to save you doing any of that, and just because I'm that kinda guy, I'll post pictures for you -- because, as everyone knows, a picture is worth a thousand tediously typed words.

Flags: needinfo?(codacodercodacoder)
Attached image image.png (deleted) —
Attached image image.png (deleted) —
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(spohl.mozilla.bugs)

Yes, it's relevant. The bug is only "very old" because it has been routinely ignored or brushed under the carpet by every Moz tech that comes across it.

Today's screen cap to follow.

Attached image Screenshot 2022-10-17 132419.png (deleted) —
Whiteboard: [win:multimonitors][win:sizing]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: