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

Categories

(Core :: Print Preview, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1b3

People

(Reporter: dholbert, Assigned: dbaron)

References

Details

(4 keywords)

Attachments

(5 files)

Attached file testcase 1
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?
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.
Keywords: testcase
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
Blocks: 468645
Keywords: assertion
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
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
We should probably just back out that one patch, then.
Assignee: nobody → dbaron
(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.
... and, as I said in bug 468645 comment 43, it was really to help us see if we could simplify the code further.
Attached patch weaken assertionSplinter Review
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)
Attachment #358517 - Flags: superreview?(bzbarsky)
Attachment #358517 - Flags: superreview+
Attachment #358517 - Flags: review?(bzbarsky)
Attachment #358517 - Flags: review+
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
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.