Closed Bug 609272 Opened 14 years ago Closed 14 years ago

Iframe containing route information doesn't show up in print preview for maps.google.com

Categories

(Core :: Print Preview, defect, P1)

Product:
Core
Component:
Print Preview
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: andreea.pod, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: regression, top100)

Attachments

(3 files)

screenshot1
490.91 KB, image/png
Details
screenshot2
38.62 KB, image/png
Details
Make sure to not apply clipping of overflow when printing to the root element, because it doesn't really make use of its overflow style itself.
14.17 KB, patch
dbaron
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101102 Firefox/4.0b8pre Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101102 Firefox/4.0b8pre First page contains the map and the rest of the pages are blank and have some lines. Reproducible: Always Steps to Reproduce: 1.Visit maps.google.com 2.Find a location to go to, then map directions from your location to there. 3.Open print preview. Actual Results: On the first page the map is shown and the next pages are blank. Expected Results: The map and additional information should appear on pages.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached image screenshot1 —
Attached image screenshot2 —
Component: General → Print Preview
Product: Firefox → Core
QA Contact: general → printing
Lots of people look for directions on google maps and they print them to find their way. I'm nominating because it's a very common use case.
blocking2.0: --- → ?
Is this a regression with respect to Firefox 3.5 or 3.6, or has this always been broken? If it is a regression, could someone track down the regression range?
It works in Firefox 3.6.12 on Linux. It does not work in Firefox trunk on Linux. The regression occurred 2010-10-06-03 (b7pre) -- 2010-10-07-03 (b8pre) http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dee1e01fd8ed&tochange=5bb4f093a50b In the former build, where it works, the map image is pushed to the 2nd page (where it appears to fit), drive directions is on the 3rd page. In the latter build, the map image appears on the first page where it doesn't fit, it's clipped and the lower part appears on the 2nd page followed by "Driving directio to ..." header but there are no directions - most of page 2 and the whole page 3 are blank.
URL: http://maps.google.com/maps?f=d&sourc...
Keywords: regression, top100
Hardware: x86 → All
Version: unspecified → Trunk
Bug 542595 seems like the most likely culprit to me.
(In reply to comment #6) > Bug 542595 seems like the most likely culprit to me. I'm not convinced; I'd like to see a narrower regression range.
Oh, I missed bug 129941 when glancing over the pushlog the first time. That bug seems much more likely, and indeed when I revert it locally I get the old behaviour.
Blocks: 129941
The issue here is that <html> is overflow:hidden in this case. But we always create a regular blockframe for the root element, because if its overflow is not visible it's propagated to the viewport. So we were doing that, but then clipping to that blockframe. We need to not do that last. Patch coming up, with testcase and all, that fixes this.
Assignee: nobody → bzbarsky
Priority: -- → P1
Whiteboard: [need review]
Keywords: testcase-wanted
Comment on attachment 490803 [details] [diff] [review] Make sure to not apply clipping of overflow when printing to the root element, because it doesn't really make use of its overflow style itself. Please double-check that using bit 28 here is ok? It should be, as far as I can see....
Attachment #490803 - Flags: review?(dbaron)
Though maybe the test should go in layout/reftests/printing....
Bit 28 looks fine, though I think it would be good to have all of the flags listed in one place (at the very least by putting in nsBlockFrame.h comments for the ones in nsHTMLParts.h). Still need to go through the rest of it.
Comment on attachment 490803 [details] [diff] [review] Make sure to not apply clipping of overflow when printing to the root element, because it doesn't really make use of its overflow style itself. r=dbaron
Attachment #490803 - Flags: review?(dbaron) → review+
Whiteboard: [need review] → [need landing]
Pushed http://hg.mozilla.org/mozilla-central/rev/2eeaa6c8d0a3
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b8
Backed out the patch for being in the range of bug 615736
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [need landing]
Pushed http://hg.mozilla.org/mozilla-central/rev/5f664ece2759 Tree is green.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [need landing]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: