STEPS TO REPRODUCE: 1. Visit about:blank (or any other page 2. Enter print-preview. 3. Resize window so that the header (and/or footer) aligns with the vertical or horizontal scrollbar. 4. Close print-preview, and enter print-preview again. ACTUAL RESULTS: Page URL in the header, page number, and datestamp are all drawn on top of scrollbars (see screenshot). NOTE: I actually see the bug at step 3, after the window resize, too. I include step 4 just for thoroughness. NOTE: If I mouseover the scrollbar, the text on top of it disappears (because the scrollbar repaints as a brighter version of itself, due to the mouse-hover) NOTE: I only see this problem with the header/footer text -- not with text in the page. BROKEN: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b2pre) Gecko/20091102 Namoroka/3.6b2pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091102 Minefield/3.7a1pre WORKING: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4 --> This is a regression in 3.6 and beyond, with respect to Firefox 3.5
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090721 Minefield/3.6a1pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090722 Minefield/3.6a1pre http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f2a58ffcd00c&tochange=02f8bf10f441 Looks like Bug 352093, Bug 500632, or Bug 503355.
(Comment 2 was the regression range for both mozilla-central and 1.9.2 -- this regressed before 1.9.2 branched off.)
dietrich says in IRC that he can reproduce this on Windows 7, with a Firefox 3.6 nighlty. OS --> All. (Note that Mac OS is unaffected since we use an external program for print-preview there.)
OS: Linux → All
I've determined that this was a regression from "Bug 352093. Part 15": http://hg.mozilla.org/mozilla-central/rev/ff084019260e based on targeted builds from that changeset and its parent.
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Created attachment 410015 [details] [diff] [review] fix: DrawHeaderFooter shouldn't ignore inherited clipping rect This patch fixes this, with a s/nsClipCombine_kReplace/nsClipCombine_kIntersect/ in nsPageFrame::DrawHeaderFooter's call to aRenderingContext.SetClipRect. The rect being passed in to SetClipRect here contains the dimensions of our page. Right now, DrawHeaderFooter requests rights to paint over that full page area, **even if our print-preview window is smaller than that.** For correct behavior, it should only request rights to paint over Intersection(FullPage,InheritedClipRect). This bug was presumably hidden until bug 352093 landed because the native scroll-widgets were painted differently (later?), and they'd paint over the excess header/footer text. However, the underlying bug here actually dates back to the initial checkin that added support for header/footer text, in bug 63426.
Created attachment 410020 [details] [diff] [review] same fix, with enhanced comment-fixage This version fixes the function's comment harder.
Attachment #410020 - Flags: review+
Attachment #410020 - Flags: approval1.9.2+
Landed: http://hg.mozilla.org/mozilla-central/rev/1fe0a013c1ac http://hg.mozilla.org/releases/mozilla-1.9.2/rev/42d3a1ac96e3
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
status1.9.2: --- → final-fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.