Closed Bug 426399 Opened 16 years ago Closed 16 years ago

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

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 411585

People

(Reporter: rjhoffma, Assigned: dholbert)

References

Details

(Keywords: regression, testcase)

Attachments

(9 files, 1 obsolete file)

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.
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)
(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)
Attached file HTML for bad boarding passes (obsolete) —
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
I attached the HTML for the case in question.
Component: General → Printing
Product: Firefox → Core
QA Contact: general → printing
Attached file 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.
Attachment #312974 - Attachment is obsolete: true
Requesting blocking -- we definitely want to be able to print boarding passes. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression, testcase
OS: Mac OS X → All
Hardware: Macintosh → All
Version: unspecified → Trunk
Note that FF2 print-previews the testcase just fine.  This is a regression.
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)
+'ing.  Yep.  People gotta fly.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Richard - thanks for the detailed bug report - very helpful!
Attached file 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.
Assignee: nobody → 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"
Summary: Cannot print boarding passes (FF 3 beta 4) → Cannot print US Airways boarding passes (FF 3 beta 4)
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.
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
(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
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.)
Blocks: 403426
(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.
(In reply to comment #19)
> I just looked at framedumps
... of testcase 2 (attachment 312995 [details])
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).
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.
Marking as a dupe, per comment 24.  Have fun, roc! :)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.