[Affected versions]: - Firefox 45.0.2 - Firefox 46 beta 10 - latest Developer Edition 47.0a2 - latest Nightly 48.0a1 [Affected platforms]: - Windows 8.1 64-bit - Windows 10 64-bit [Steps to reproduce]: - prerequisits: hidpi and lowdpi monitor 1. Open Firefox 2. Drag Firefox on lowdpi monitor (if it does not open there from the start). 3. Move Firefox to hidpi monitor just a little, just before it resizes on hidpi). 4. Click Hello or Pocket icon. (Hello issue is a bit intermittent, sometimes it keeps the text size of the piece of Firefox that has been moved to hidpi but with pocket I can repro each time) extra step for navbar icons hidden in dropdown: 5. Move the window to lowdpi again. [Expected result]: - Text from Hello and Pocket panels is scaled with the piece of Firefox that is in transition of moving from one screen to another. [Actual result]: - Hello and Pocket panels have their text scaled to hidpi or lowdpi text even though FF is in transition between the screens (same as other panels from FF: bookmarks, downloads, hamburger etc) [Regression range]: - This is not a regression, it reproduces with old Nightly (2016-01-13). [Additional notes]: - Since this also reproduces on 45 and 46, I am not sure this is related to per-monitorDPI feature or not.

The problem here happens when the popup is opened on the 'minor' part of the browser window, so its LogToPhysFactor is based on a different screen from the parent window's, yet they share a root presContext with a single appUnit scale. To fix this, we should make the popup always follow the DPI setting that is being used by the parent window, so that we have consistent window sizing and contents scaling for the whole of the window and its popup panels.

Comment on attachment 8740853 [details] [diff] [review] Use the DPI from the parent window, if any, for consistency between popups and their owners when straddling a monitor boundary Review of attachment 8740853 [details] [diff] [review]: ----------------------------------------------------------------- ::: widget/windows/WinUtils.h @@ +148,5 @@ > + // if there's a parent, we want to share its DPI setting > + HWND parent = ::GetParent(aWnd); > + if (parent) { > + return LogToPhysFactor(parent); > + } ::GetAncestor(aWnd, GA_ROOTOWNER) would be better. You don't have to call LogToPhysFactor recursively with this.

Updated patch to use GetAncestor, as suggested; carrying over r=emk.

https://hg.mozilla.org/integration/mozilla-inbound/rev/3bcaa74cc73a490cc7f2c309b72009dd229a41dc Bug 1264196 - Use the DPI from the parent window, if any, for consistency between popups and their owners when straddling a monitor boundary. r=emk

I confirm this is fixed using latest Nightly on Windows 10 64-bit and Windows 8.1 64-bit. The text does scale properly now.

Comment on attachment 8740928 [details] [diff] [review] Use the DPI from the parent window, if any, for consistency between popups and their owners when straddling a monitor boundary Approval Request Comment [Feature/regressing bug #]: 890156 [User impact if declined]: bad rendering of some pop-up panels (Hello, Pocket; possibly others from add-ons, etc) in some cases when a browser window is straddling two displays with different DPI [Describe test coverage new/current, TreeHerder]: manually tested [Risks and why]: low-risk patch to ensure child windows follow the scaling of their parent [String/UUID change made/needed]: none

Comment on attachment 8740928 [details] [diff] [review] Use the DPI from the parent window, if any, for consistency between popups and their owners when straddling a monitor boundary Per-monitor DPI related, Aurora47+

remote: https://hg.mozilla.org/releases/mozilla-aurora/rev/17cf0270b190

Verified fixed using latest Developer Edition 48.a2 and Firefox 47 beta 1 on Windows 10 and Windows 8.1.