Closed Bug 1041200 Opened 5 years ago Closed 5 years ago
going back a page (or changing tabs) incompletely redraws it, when zoomed in with full-page-zoom
What did you do? (steps to reproduce) 1/ open any page or bug 1022612 2/ zoom in (Ctrl + MouseWheelUp) a few times 3/ click on any link or one of m-i links in bug 1022612 comment 92 4/ zoom in (Ctrl + MouseWheelUp) a few times 5/ press Back and Forward buttons to switch between pages What happened? (actual results) Remnants of previous page often seen around current one contents What should have happened? (expected results) Only current page drawn
I can see the problem on Windows7 if HWA=off and OMTC=off. https://hg.mozilla.org/integration/mozilla-inbound/rev/24a69de91baa Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140719065519 Graphics -------- Adapter Description: ATI Radeon HD 4300/4500 Series Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 512 ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 50 Enhanced Contrast: 200 Device ID: 0x954f DirectWrite Enabled: false (6.2.9200.16492) Driver Date: 4-29-2013 Driver Version: 8.970.100.1100 GPU #2 Active: false GPU Accelerated Windows: 0/1 Basic Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: false AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0
OS: FreeBSD → All
I can reproduce the problem on ubuntu 12.04. Graphics -------- Adapter Description: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE; Device ID: Gallium 0.4 on SVGA3D; build: RELEASE; Driver Version: 2.1 Mesa 8.0.4 GPU Accelerated Windows: 0/1 Basic Vendor ID: VMware, Inc. WebGL Renderer: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE; windowLayerManagerRemote: false AzureCanvasBackend: cairo AzureContentBackend: cairo AzureFallbackCanvasBackend: none AzureSkiaAccelerated: 0
This happens because nsDisplayZoom is computing the wrong mVisibleRect. Currently the dirtyrect we use to compute the visible rect is in the appunit coordinates of the subdocument. Also, nsDisplayZoom's mToReferenceFrame is in the appunits of the subdocument. So we compute a visible rect in the appunits of the subdocument, but of course it gets used in the appunits of the outer document. nsDisplayResolution, and nsDisplaySubdocument (when aFrame is the subdocument root frame) have the same problems. I'm not sure the best way to fix this. Guess I'll sleep on it :-). We need to think about what mToReferenceFrame should mean for these display items, as well as fixing mVisibleRect.
Shouldn't we treat nsDisplayZoom the same as nsDisplayTransform? Where the children are considered to be in a different coordinate space to the parent?
We could, but then we'd need to make it a reference frame. Can you see any problems with that?
Summary: going back a page incompletely redraws it → going back a page (or changing tabs) incompletely redraws it, when zoomed in with full-page-zoom
5 years ago
Assignee: nobody → roc
Status: NEW → ASSIGNED
5 years ago
Attachment #8460015 - Flags: review?(matt.woodrow) → review+
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Duplicate of this bug: 1041608
testday-20141107 Windows 8.1. 64 bit, en-US VERIFIED FIXED
You need to log in before you can comment on or make changes to this bug.