426399 - Cannot print US Airways boarding passes (FF 3 beta 4)

Status: RESOLVED DUPLICATE of bug 411585

(Core :: Printing: Output, defect, P2)

Description

[Richard Hoffmann]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4

I just tired to print boarding passes after checking in for a flight on the USAirways web site. All that came out were blank sheets with header information. I captured the output in a pdf, which contains eight nearly blank pages and the final page of printed instructions.

This is not the only instance where FF has similarly failed to produce a useable printed copy of web output, but I cannot recall the other example.

Safari handles this task properly.

Reproducible: Always

Steps to Reproduce:
1.Go to USAirways.com
2.Select Check In for Flight.
3.Enter flight information
4.Observe the boarding passes in a new tab.
5.Press Print Boarding Passed button.
6.Observe blank pages from printer
Actual Results:  
Blank or nearly blank pages are all that result. No useable boarding pass is produced. Reprinting passes through Safari produces acceptable passes.

Expected Results:  
Expected suitable boarding passes

I have retained a pdf of the actual results of this adventure, if that would be useful to someone looking into this.

Comment 1

[Richard Hoffmann]

Attachment: PDF file of bad printer output.

Comment 2

[Daniel Holbert [:dholbert]]

Richard:  Could you attach the HTML of the boarding pass, with any personal information removed?  (via File | Save As, make sure "Web Page, Complete" is selected)

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to comment #2)
> Richard:  Could you attach the HTML of the boarding pass, with any personal
> information removed?  (via File | Save As, make sure "Web Page, Complete" is
> selected)

(I meant to say -- if that's ok, please zip up the saved output, and attach the zip file)

Comment 4

[Richard Hoffmann]

Attachment: HTML for bad boarding passes

HTML of plane checking. I can confirm that this will not print properly though FF 3 beta 4, but it will thought Safari 3.1

Comment 5

[Richard Hoffmann]

I attached the HTML for the case in question.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Thanks, Richard.

Here's the same testcase, but with the "onload=window.print()" removed.

The issue shows up in Print-Preview (on Linux) as well.

Comment 8

[Daniel Holbert [:dholbert]]

Requesting blocking -- we definitely want to be able to print boarding passes. :)

Comment 9

[Daniel Holbert [:dholbert]]

Note that FF2 print-previews the testcase just fine.  This is a regression.

Comment 10

[Daniel Holbert [:dholbert]]

Removing these (missing) "spacer" images seems to fix the bug:
  <img src='/common/resources/_images/spacer.gif' width='612' height='900'>

These img tags have large height/width, and they seem to draw on top of the rest of the page's content in Print/Print-Preview.  (but they go behind everything when viewed normally in the browser)

Comment 11

[Damon Sicore (:damons)]

+'ing.  Yep.  People gotta fly.

Comment 12

[Mike Schroepfer]

Richard - thanks for the detailed bug report - very helpful!

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced)

Here's a reduced testcase.  Both "AAAA" and "BBBB" should show up in print-preview, but only "AAAA" does.

If I reduce the image's height so that it fits on the first page, the bug goes away.

That leads me to believe that this is related to bug 411585. i.e. I think this is a situation where we have an absolutely positioned element on the first page whose placeholder gets pushed to the second page.

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to comment #13)
> Here's a reduced testcase.  Both "AAAA" and "BBBB" should show up in
> print-preview, but only "AAAA" does.

Er, make that "AAA" and "BBB"

Comment 15

[Daniel Holbert [:dholbert]]

Hm -- testcase 2's regression window is between 2007-12-02 and 2007-12-03.  

However, testcase 1 still works on 2007-12-03, so there must be another problem that regressed and that testcase 2 doesn't capture.

Comment 16

[Daniel Holbert [:dholbert]]

testcase 1's regression window seems to be between 2008-03-19 and 2008-03-20.

(I know that doesn't completely make sense, seeing as the bug was reported in FF3b4 which closed pre-2008-03-19...  But I'm definitely getting working behavior in the 2008-03-19 Linux nightly.)

Bonsai link: http://tinyurl.com/22r2l9

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to comment #15)
> testcase 1's regression window seems to be between 2008-03-19 and 2008-03-20.
>(I know that doesn't completely make sense...

Aha!  The 2008-03-20 change wasn't actually a regression -- it just exposed the regression on this testcase.  The change here was that bug 417356 landed, increasing the printed margins (and decreasing the imageable area) on Linux.  This change made the 900px-high image, which used to barely fit on the page, no longer fit.  (testcase 2 was broken in earlier builds because it uses a taller 1000px-high image, which never fit on one page in the first place.)

So, anyway -- the "testcase 1's regression range" from comment 16 is bogus.  

The real regression window is the one mentioned in Comment 15 --  between 2007-12-02 and 2007-12-03.

Bonsai link: http://tinyurl.com/26lz2u

Comment 18

[Daniel Holbert [:dholbert]]

I tried backing out various patches in the regression range, to see what caused this.

Bug 403426 seems to have been the cause.  (backing out its patch from a 2007-12-03 build fixes this.)

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to comment #13)
> I think this
> is a situation where we have an absolutely positioned element on the first page
> whose placeholder gets pushed to the second page.

I just looked at framedumps from builds around bug 403426 landing.
  - Before bug 403426, both placeholders are on the first page.
  - After bug 403426, the "BBB" div's placeholder is on the second page.

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to comment #19)
> I just looked at framedumps
... of testcase 2 (attachment 312995 [details])

Comment 21

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (little whitespace)

Interestingly, the bug reproduces if there's whitespace before both div 'a' and div 'b' (as in this testcase), but it *won't* reproduce if we remove either of those spaces (as shown in upcoming reference cases).

Comment 22

[Daniel Holbert [:dholbert]]

Attachment: reference 3a (removed whitespace before 'a')

Comment 23

[Daniel Holbert [:dholbert]]

Attachment: reference 3b (removed whitespace before 'b')

Comment 24

[Daniel Holbert [:dholbert]]

Attachment: testcase 4a (no whitespace; text before 'a')

This testcase, and the upcoming testcase 4b, have a much older regression range -- it's the same one as bug 411585, in fact.  (which makes sense, given Comment 13)

So, I'm pretty sure that this bug is generally a dupe of that bug, and the more recent regression was that the bug expanded to happen in slightly more situations.

Comment 25

[Daniel Holbert [:dholbert]]

Attachment: testcase 4b (no whitespace; text before 'b')

Comment 26

[Daniel Holbert [:dholbert]]

Attachment: reference 4 (no whitespace; text after both divs)

Comment 27

[Daniel Holbert [:dholbert]]

Marking as a dupe, per comment 24.  Have fun, roc! :)