Closed Bug 817454 Opened 12 years ago Closed 11 years ago

[HiDPI] corrupted layout on LoDPI screens after zooming

Categories

(Core :: Layout, defect)

18 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla21
Tracking Status
firefox18 --- disabled
firefox19 --- disabled
firefox20 + fixed
firefox21 --- fixed

People

(Reporter: chrille_b, Assigned: jfkthame)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20121130 Firefox/20.0
Build ID: 20121130114656

Steps to reproduce:

I open firefox and open a website (e.g. www.google.de). The window has appeared on the primary HiDPI screen. Then I moved the window to a LoDPI screen and i press CMD key and plus or minus key to zoom in or out. 


Actual results:

The layout is a little bit corrupted. It is like layout is computed on wrong devicPixelRatio or something. Also window.devicePixelRatio is a bit strange. The number reported by web console is something like 0.89552241563797 on LoDPI screen.

See attached screenshot.


Expected results:

The layout should not be corrupted.
devicePixelRatio must be one on LoDPI screens and two on HiDPI screen.
Blocks: osx-hidpi
This bug occurs also when website is rendered on LoDPI screen and moved to HiDPI screen. This bug does not occur when the page rendered again before moving it (e.g. when pressing CMD+ALT+K for web console) to a different HiDPI/LoDPI screen.
(In reply to chrille_b from comment #0)
> Expected results:
> 
> The layout should not be corrupted.

Indeed - looks like something isn't being updated correctly for the move. I'll try to look into this.

> devicePixelRatio must be one on LoDPI screens and two on HiDPI screen.

No, devicePixelRatio will vary depending on the zoom - it's 1.0 (lo-dpi) or 2.0 (hi-dpi) at the default zoom level, but zooming will alter this.

(This issue was recently discussed on the www-style list, as current implementations vary between browsers; the message thread begins with http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html. See also bug 809788.)
>(In reply to Jonathan Kew (:jfkthame) from comment #2)
> (In reply to chrille_b from comment #0)
> > Expected results:
> > 
> > The layout should not be corrupted.
> 
> Indeed - looks like something isn't being updated correctly for the move.
> I'll try to look into this.

To clarify the behavior of this bug. It seems to occur when moving the browser window from lo-dpi to a hi-dpi screen or vice versa. And then zooming in or out and only if the window was not re-rendered. 

If the layout is corrupted and the window is re-rendered (e.g. after resizing window), the layout is okay.

> > devicePixelRatio must be one on LoDPI screens and two on HiDPI screen.
> 
> No, devicePixelRatio will vary depending on the zoom - it's 1.0 (lo-dpi) or
> 2.0 (hi-dpi) at the default zoom level, but zooming will alter this.

Ah, okay. After reading www-style list discussion this makes sense.
Just confirming this is still present on trunk. It's most obvious if you open a window on a lo-dpi screen, then drag it to a hi-dpi one, and then zoom in or out: although the dragged window initially looks fine on the destination screen, as soon as it is zoomed, the content area shrinks to fill only the top-left quarter of the window.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The problem here arises because the PresContext keeps a cached copy of the appUnitsPerDevPix value, but currently that value only gets updated during zoom or window-resize. We also need to ensure it gets updated when the backing scale factor changes, otherwise the next zoom operation bases its size calculations on the wrong scale.
Attachment #710151 - Flags: review?(roc)
Assignee: nobody → jfkthame
Tryserver build in progress: https://tbpl.mozilla.org/?tree=Try&rev=8327111c488d.
chrille_b, if you'd like to confirm this fixes the problem for you, that'd be great - thanks.
I can confirm that this bug is fixed in your tryserver build.

Good work! And thank you.
Component: Untriaged → Layout
Product: Firefox → Core
Comment on attachment 710151 [details] [diff] [review]
ensure PresContext's cached mAppUnitsPerDevPixel value is updated when backing resolution changes

Requesting approval to uplift this for FF20, along with the rest of multi-screen HiDPI support. (Not required for FF19 because bug 814434 has preffed-off  HiDPI support for systems with mixed hi- and lo-dpi displays)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): HiDPI (Retina) support when external non-hidpi screen is also present

User impact if declined: wrongly scaled display if a window is moved between screens and then zoomed in or out

Testing completed (on m-c, etc.): tested locally, fix confirmed by reporter in tryserver build, now on inbound

Risk to taking this patch (and alternatives if risky): minimal risk - simple patch with no effect on behavior unless mixed lo- and hi-dpi displays are present

String or UUID changes made by this patch: none
Attachment #710151 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/c2f402470a49
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #710151 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: