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

Status: NEW

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

Description

[Codacoder]

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.

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 2

[Codacoder]

No, only those mentioned.  Far worse is "bug 1".  My original title was better.

Comment 3

[Codacoder]

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

Comment 4

[Codacoder]

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.

Comment 5

[Girish Sharma [:Optimizer]]

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.

Comment 6

[Codacoder]

Try a three monitor setup?

Comment 7

[Girish Sharma [:Optimizer]]

I don't have one. Can you paste a screenshot of the issue btw ? properly explaining all three monitor's properties alongside ?

Comment 8

[Codacoder]

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 ;)

Comment 9

[Codacoder]

Attachment: screenshot

Comment 10

[Codacoder]

The popup in the image is jammed between mon1 and 2.

Comment 11

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 12

[Codacoder]

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 ;)

Comment 13

[Rob Campbell [:rc] (:robcee)]

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.

Comment 14

[Codacoder]

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

Comment 15

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

This is a platform bug.

Comment 16

[Codacoder]

Sorry,Nick, can you expand on that?  What does that mean exactly?

Comment 17

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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

Comment 18

[Codacoder]

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?

Comment 19

[Codacoder]

Add console popups (eg suggestions) to the affected UI components.

Comment 20

[Paul Silaghi, QA [:pauly]]

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

Comment 21

[Codacoder]

Attachment: 967096-2.png

You actually don't need an extra monitor. Latest Nightlies have been doing this on primary alone.  See attachment.

Comment 22

[Paul Silaghi, QA [:pauly]]

I can't reproduce that both on primary/second monitor, nightly 31.0a1(2014-03-26), Win 7 x64.

Comment 23

[Codacoder]

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.

Comment 24

[u279076]

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.

Comment 25

[Codacoder]

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

Comment 26

[u279076]

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?

Comment 27

[Jeff Griffiths (:canuckistani) (:⚡︎)]

*bump*, would be good to get try to repro here.

Comment 28

[juan becerra [:juanb]]

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.

Comment 29

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Thanks for the update, Juan!

Comment 30

[juan becerra [:juanb]]

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?

Comment 31

[Codacoder]

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

Comment 32

[Codacoder]

Attachment: 967096-3.png

Comment 33

[Codacoder]

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

Comment 34

[Rob Campbell [:rc] (:robcee)]

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.

Comment 35

[Codacoder]

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.

Comment 36

[Codacoder]

Attachment: about-support.txt

Juan, as requested.

Comment 37

[Patrick Brosset <:pbro>]

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.

Comment 39

[Codacoder]

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.

Comment 40

[Codacoder]

(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) :/

Comment 42

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 43

[Codacoder]

(In reply to Release mgmt bot [:sylvestre / :calixte] from comment #42)

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

I assume that means it'll get even less attention?

This is still a problem. Firefox is just plain weird on a multi-monitor setup - Quantum, too. Debugger is better. Options UI is a faulty - any dropdown/select will appear on the wrong screen.

But have it your way. Stay broken.

Comment 44

[lilydjwg]

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

Comment 45

[Vlad Lucaci, Desktop QA (:vlucaci)]

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?

Comment 46

[Codacoder]

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.

Comment 47

[Codacoder]

Attachment: Screenshot 2021-01-28 100554.png

Comment 48

[Codacoder]

Attachment: Screenshot 2021-01-28 100315.png

Comment 49

[Jim Mathies [:jimm]]

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.

Comment 50

[Jim Mathies [:jimm]]

Attachment: split screen example.jpg

Comment 53

[Codacoder]

(In reply to Jim Mathies [:jimm] from comment #49)

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

Well that's unhelpful. I'm glad you found an obscure example (of potentially a different issue) to justify doing nothing.

There are many reasons Firefox is (has been) losing market share. Can't in all honesty say this bug is one of them, but the approach?

I do wonder.

Just saying.

Comment 54

[Jim Mathies [:jimm]]

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!

Comment 55

[Codacoder]

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.

Comment 56

[Codacoder]

Attachment: image.png

Comment 57

[Codacoder]

Attachment: image.png

Comment 58

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 59

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 60

[Codacoder]

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.

Comment 61

[Codacoder]

Attachment: Screenshot 2022-10-17 132419.png