Open Bug 1239347 Opened 4 years ago Updated Last year

Incorrect scaling when a lo-DPI window opens a hi-DPI window.

Categories

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

defect

Tracking

()

People

(Reporter: mhoye, Unassigned)

Details

(Whiteboard: tpi:+)

Attachments

(1 file, 1 obsolete file)

See here - http://i.imgur.com/M0Mw4AI.png 

STRs are as described, when a window on a standard monitor opens a dialog on a HiDPI monitor. The autocomplete menu is exactly where it should be there, but the contents of the window are half their expected size.
Hey spohl, I've also been periodically seeing popups being positioned strangely on Yosemite after plugging in an external monitor (the awesomebar dropdown, for example). Do you know if anybody in #macdev is most savvy on dpi switching bugs?
Flags: needinfo?(spohl.mozilla.bugs)
Forwarding to mstange who might be able to help.
Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(mstange)
The title bar being scaled incorrectly (in my case: high dpi laptop, low dpi external monitor) happens on Windows, too. Is my anecdotal evidence enough to move this out of Widget: Cocoa?
Jonathan is doing work in this area at the moment, forwarding to him.
Flags: needinfo?(mstange) → needinfo?(jfkthame)
In initial testing, I can't seem to reproduce what's shown in the screenshot, but I wonder if this is some form of the same issue as bug 1248675. Do you have HWA disabled, by any chance? Does it make any difference whether it's on or off?

Oh, and which is the primary screen (with the menubar when looking in the Displays/Arrangement prefs panel), the lo- or hi-dpi one?
Flags: needinfo?(jfkthame) → needinfo?(mhoye)
(In reply to Andrew Overholt [:overholt] from comment #3)
> The title bar being scaled incorrectly (in my case: high dpi laptop, low dpi
> external monitor) happens on Windows, too. Is my anecdotal evidence enough
> to move this out of Widget: Cocoa?

On Windows, the title bar doesn't scale according to the monitor DPI; it's always drawn at the same device-pixel size based on the DPI of the primary monitor. That's a "feature", not a bug. (I.e. that's how Windows is documented to work, even though it can look pretty weird if the resolutions are substantially different.)
Attached image Window of Firefox also buggy (obsolete) —
:mhoye, can you still reproduce this with current Nightly (or Aurora, or Beta)? I'm hoping bug 1248675 may have resolved it... please confirm whether it's still an issue for you.
Flags: needinfo?(twalker)
Mike, are you still seeing this with latest Nightly builds.  I am unable to reproduce this bug with Nightly 50.0a1, 20160608030219 on Mac 10.11.2.  (perhaps my external monitor has too high resolution)
Flags: needinfo?(twalker)
Flags: needinfo?(mhoye)
Flags: needinfo?(mhoye)
You've asked at just the right moment. I couldn't reproduce this right up until yesterday's nightly, but now I can again! 

http://i.imgur.com/lO3Q8rF.png

My physical setup is unchanged; recent MBP running Yosemite, external non-hidpi monitor attached and rotated sideways. Nightly up to date as of right now.
Flags: needinfo?(mhoye)
I think this is Yosemite only, as I am unable to reproduce on El Capitan.
I'm sorry, I misspoke - I'm also on El Cap.
Hmmm, ok. What resolution is your external monitor?  I have an HP 25xi running at 1080p.
Dell U2413, running at native 1920x1200 rotated on the external monitor, connected via Thunderbolt-to-DVI.
Flags: needinfo?(mhoye)
I had tried with rotated external monitor.  I have external monitor connected via HDMI cable.
Attachment #8741753 - Attachment is obsolete: true
Priority: -- → P2
Whiteboard: tpi:+
I've started seeing this again: http://i.imgur.com/CLSCPAd.png
Huh, that's annoying - I thought we'd stamped this out.

What version are you on (nightly? release?), and can you give an exact sequence of STR? Can you identify a regression range, if it wasn't happening for some time, and now came back?
Current nightly, current OSX, I'll get you STRs as soon as I can make it happen reliably.
mconley, since this is in a window.open()ed window, maybe bug 1261842 somehow caused this?
Flags: needinfo?(mconley)
I suppose it's possible?

mhoye, when you see this, is the window that's opening the Persona popup on the same display as the one where the popup appears?
Flags: needinfo?(mconley) → needinfo?(mhoye)
Nope. This only occurs when a Firefox window on a lo-DPI display opens on a HiDPI window.
Flags: needinfo?(mhoye)
(Or rather, opens a new window on a HiDPI display.)
One more question - does the original browser on the lo-DPI display have a non-default zoom factor set on it? (We have an indicator in the URL bar for the zoom factor on the page).
Flags: needinfo?(mhoye)
Nope. Standard zoom levels all 'round. 

For what it's worth, the part of reproducing this that I'm strugging with is the sequence that will cause a tab on one screen to think that its pop-ups should appear on a different screen. Once I can make that start happening, it's trivially reproducible but I'm not sure how I cause that to occur.
Flags: needinfo?(mhoye)
I also got this problem on Windows 10 when I want to print from Firefox and my TV is used as second screen. The print dialogue is opening not on the standard monitor where Firefox is shown, but on the TV, which is set to 150% scaling. I tested it without the TV and everything is normal then. Furthermore, I tested the print dialogue with another application (Sumatra  PDF) and there are no issues. I am not 100% sure wether this problem is related to Firefox, but this bug report is supporting my guess.
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.