Closed
Bug 472353
Opened 16 years ago
Closed 16 years ago
Zooming in print-preview grows & moves scrollbars, doesn't repaint, causes graphical corruption, doesn't scale actual content
Categories
(Core :: Print Preview, defect, P2)
Core
Print Preview
Tracking
()
RESOLVED
FIXED
mozilla1.9.1b3
People
(Reporter: dholbert, Assigned: dbaron)
References
Details
(4 keywords)
Attachments
(5 files)
6 bytes,
text/plain
|
Details | |
20.94 KB,
image/png
|
Details | |
29.85 KB,
image/png
|
Details | |
32.06 KB,
image/png
|
Details | |
3.81 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
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:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Reporter | ||
Updated•16 years ago
|
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
Reporter | ||
Comment 1•16 years ago
|
||
Reporter | ||
Comment 2•16 years ago
|
||
This is a recent regression, I think; the mobile guys were complaining about similar brokenness when zooming as of a few days ago.
Reporter | ||
Comment 4•16 years ago
|
||
Reporter | ||
Comment 5•16 years ago
|
||
I'll track down a regression range. brb...
Reporter | ||
Comment 6•16 years ago
|
||
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
Reporter | ||
Comment 7•16 years ago
|
||
hg link for regression range: http://tinyurl.com/8ff55x
My guess is that one of the patches for bug 468645 is responsible.
Reporter | ||
Comment 8•16 years ago
|
||
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
Updated•16 years ago
|
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Comment 9•16 years ago
|
||
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
Reporter | ||
Comment 10•16 years ago
|
||
(In reply to comment #9)
Thanks! Setting Platform --> All/All
Hardware: x86 → All
Priority: -- → P2
Assignee | ||
Comment 11•16 years ago
|
||
We should probably just back out that one patch, then.
Assignee: nobody → dbaron
Assignee | ||
Comment 12•16 years ago
|
||
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.
Assignee | ||
Comment 13•16 years ago
|
||
(And, oh, by the way, hooray for undiscoverable features making me think we don't support them.)
Assignee | ||
Comment 14•16 years ago
|
||
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.
Assignee | ||
Comment 15•16 years ago
|
||
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).
Assignee | ||
Comment 16•16 years ago
|
||
... and, as I said in bug 468645 comment 43, it was really to help us see if we could simplify the code further.
Assignee | ||
Comment 17•16 years ago
|
||
This weakens the assertion added and adds some more comments to reflect the messiness of the current situation.
Attachment #358517 -
Flags: superreview?(bzbarsky)
Attachment #358517 -
Flags: review?(bzbarsky)
![]() |
||
Updated•16 years ago
|
Attachment #358517 -
Flags: superreview?(bzbarsky)
Attachment #358517 -
Flags: superreview+
Attachment #358517 -
Flags: review?(bzbarsky)
Attachment #358517 -
Flags: review+
Assignee | ||
Comment 18•16 years ago
|
||
OK, assertion fix landed as well, which makes this fixed:
http://hg.mozilla.org/mozilla-central/rev/dc1587c310b8
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [needs 1.9.1 landing]
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Comment 19•16 years ago
|
||
Assertion fix landed on 1.9.1 as well:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/df73346fba12
Flags: in-testsuite?
Keywords: fixed1.9.1
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.
Description
•