Closed Bug 472353 Opened 13 years ago Closed 13 years ago
Zooming in print-preview grows & moves scrollbars, doesn't repaint, causes graphical corruption, doesn't scale actual content
6 bytes, text/plain
20.94 KB, image/png
29.85 KB, image/png
32.06 KB, image/png
3.81 KB, patch
|Details | Diff | Splinter Review|
This is a pretty serious Print-Preview regression from Firefox 3. STEPS TO REPRODUCE ================== EXPERIMENT A: ZOOM-OUT: 1. Print-preview the attached testcase in a not-very-tall window (to force a vertical scrollbar during print-preview) 2. Zoom out (Hold 'Ctrl' and scroll mousewheel downwards) 3. Minimize the Print-Preview window, and then restore it (forcing a repaint) EXPERIMENT B: ZOOM-IN: 1. Print-preview the attached testcase in a not-very-tall window (to force a vertical scrollbar 2. Zoom in (Hold 'Ctrl' and scroll mousewheel upwards) 3. Minimize the Print-Preview window, and then restore it (forcing a repaint) ACTUAL RESULTS: (a) Results of zooming aren't visible until after we force a repaint in Step 3 (b) The scrollpane itself gets scaled as well -- i.e. the scrollbars change size & position. (and dead space is introduced, when we zoom out) (c) Original scrollbar location is replaced with graphical corruption (d) Zooming doesn't scale the page contents "a b c" at all (though it does scale the page-header text) EXPECTED RESULTS: (a) Results of zoom should be visible immediately (at step 2) (b) Zooming shouldn't scale the scrollpane itself (scrollbars should stay fixed in position & size) (c) There shouldn't be graphical corruption (d) Page contents should be scaled according to zoomlevel. I can reproduce this in mozilla-central and 1.9.1 nightlies, but not in Firefox 3.0.5. Build IDs are below. BROKEN: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090103 Minefield/3.2a1pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090106 Shiretoko/3.1b3pre WORKING: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5
Summary: Zooming in print-preview grows & moves scrollbars, doesn't repaint, and causes graphical corruption → Zooming in print-preview grows & moves scrollbars, doesn't repaint, causes graphical corruption, doesn't scale actual content
This is a recent regression, I think; the mobile guys were complaining about similar brokenness when zooming as of a few days ago.
I'll track down a regression range. brb...
Regression range is between 12/29 and 12/30: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20081229 Minefield/3.2a1pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20081230 Minefield/3.2a1pre
hg link for regression range: http://tinyurl.com/8ff55x My guess is that one of the patches for bug 468645 is responsible.
Confirmed -- this broke when bug 468645 landed. Specifically, the following patch caused this bug (on mozilla-central and mozilla-1.9.1, respectively): http://hg.mozilla.org/mozilla-central/rev/6849ce51dfef http://hg.mozilla.org/releases/mozilla-1.9.1/rev/982c8f0d834c In an up-to-date debug build, each time I zoom in print-preview, I hit that patch's NOTREACHED ("not allowed to rebuild all style data when paginated"), and its subsequent early return. ( --> adding 'assertion' keyword ) When I 'hg backout' that patch, this bug goes away. But instead of this bug, I get 3 copies of this assertion each time I zoom during print-preview: ###!!! ASSERTION: frame must have content (unless viewport): 'aFrame->GetContent() || !aFrame->GetParent()', file nsFrameManager.cpp, line 1116
Confirmed to occur on the latest Windows Minefield nightly as well Mozilla/5.0 (Windows; U; Windows NT 6.1; en-IN; rv:1.9.2a1pre) Gecko/20090120 Minefield/3.2a1pre (.NET CLR 3.5.30729) Ubiquity/0.1.5
OS: Linux → All
(In reply to comment #9) Thanks! Setting Platform --> All/All
Hardware: x86 → All
Priority: -- → P2
We should probably just back out that one patch, then.
Assignee: nobody → dbaron
I backed it out: http://hg.mozilla.org/mozilla-central/rev/6f2d2ef53d75 http://hg.mozilla.org/mozilla-central/rev/2a1f13246939 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f3745d8868f0 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b5dad31a8a15 This still needs a patch to fix up the assertion appropriately.
(And, oh, by the way, hooray for undiscoverable features making me think we don't support them.)
So the deal with the assertions is that right now the page structure in print preview looks like: Viewport (content=0) HTMLScroll (content=html) two scrollbars (with their own anonymous content) SimplePageSequence (content=html) Page (content=0) PageContent (content=0) Canvas (content=0) Block (content=html) so we assert on Page, PageContent, and Canvas.
For the record, the assertion is from http://hg.mozilla.org/mozilla-central/rev/dee577166dd8 (bug 468645 patch 4) and http://hg.mozilla.org/mozilla-central/rev/2e16533cc07e (bug 468645 comment 49).
... and, as I said in bug 468645 comment 43, it was really to help us see if we could simplify the code further.
This weakens the assertion added and adds some more comments to reflect the messiness of the current situation.
OK, assertion fix landed as well, which makes this fixed: http://hg.mozilla.org/mozilla-central/rev/dc1587c310b8
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs 1.9.1 landing]
Target Milestone: --- → mozilla1.9.2a1
Assertion fix landed on 1.9.1 as well: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/df73346fba12
Whiteboard: [needs 1.9.1 landing]
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
You need to log in before you can comment on or make changes to this bug.