Closed
Bug 426399
Opened 17 years ago
Closed 17 years ago
Cannot print US Airways boarding passes (FF 3 beta 4)
Categories
(Core :: Printing: Output, defect, P2)
Core
Printing: Output
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.
Reporter | ||
Comment 1•17 years ago
|
||
Assignee | ||
Comment 2•17 years ago
|
||
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)
Assignee | ||
Comment 3•17 years ago
|
||
(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)
Reporter | ||
Comment 4•17 years ago
|
||
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
Reporter | ||
Comment 5•17 years ago
|
||
I attached the HTML for the case in question.
Updated•17 years ago
|
Component: General → Printing
Product: Firefox → Core
QA Contact: general → printing
Assignee | ||
Comment 7•17 years ago
|
||
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
Assignee | ||
Comment 8•17 years ago
|
||
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
Assignee | ||
Comment 9•17 years ago
|
||
Note that FF2 print-previews the testcase just fine. This is a regression.
Assignee | ||
Comment 10•17 years ago
|
||
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•17 years ago
|
||
+'ing. Yep. People gotta fly.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Comment 12•17 years ago
|
||
Richard - thanks for the detailed bug report - very helpful!
Assignee | ||
Comment 13•17 years ago
|
||
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 | ||
Updated•17 years ago
|
Assignee: nobody → dholbert
Assignee | ||
Comment 14•17 years ago
|
||
(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"
Assignee | ||
Updated•17 years ago
|
Summary: Cannot print boarding passes (FF 3 beta 4) → Cannot print US Airways boarding passes (FF 3 beta 4)
Assignee | ||
Comment 15•17 years ago
|
||
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.
Assignee | ||
Comment 16•17 years ago
|
||
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
Assignee | ||
Comment 17•17 years ago
|
||
(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
Assignee | ||
Comment 18•17 years ago
|
||
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
Assignee | ||
Comment 19•17 years ago
|
||
(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.
Assignee | ||
Comment 20•17 years ago
|
||
(In reply to comment #19)
> I just looked at framedumps
... of testcase 2 (attachment 312995 [details])
Assignee | ||
Comment 21•17 years ago
|
||
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).
Assignee | ||
Comment 22•17 years ago
|
||
Assignee | ||
Comment 23•17 years ago
|
||
Assignee | ||
Comment 24•17 years ago
|
||
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.
Assignee | ||
Comment 25•17 years ago
|
||
Assignee | ||
Comment 26•17 years ago
|
||
Assignee | ||
Comment 27•17 years ago
|
||
Marking as a dupe, per comment 24. Have fun, roc! :)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•