Closed Bug 692711 Opened 10 years ago Closed 10 years ago

Categories

(Core :: Printing: Output, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 531200

People

(Reporter: steve.chessin, Unassigned)

References

()

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

I am using Firefox 7.0.1 on a MacBookPro running Mac OS X 10.5.8 (9L31a).

Go to http://www.green960.com/pages/lineup.html

Click on the first "Print article", just under "listen live". When the Print dialogue pops up, select Preview. The first page shown is almost all blank, the second page shows the last two programs.

Now do the same in Safari. (You'll have to select "Open PDF in Preview" from the PDF menu.) The first page shows the first five shows, and the second page shows the next three.

(The second "Print article", the one just above "Weekend Programs", works fine.)

I've attached a zip file containing two PDFs; one is the output of Firefox, the other
is the output of Safari.  They illustrate the problem.


Actual results:

The first page shown is almost all blank, the second page shows the last two programs.



Expected results:

The first page should show the first five shows, and the second page should show the next three.
Confirming on Linux Trunk (using Print Preview at the last step, instead of real printing)
Mozilla/5.0 (X11; Linux i686; rv:10.0a1) Gecko/20111005 Firefox/10.0a1
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: 7 Branch → Trunk
It works fine for me on Linux Trunk using A4 paper size.  I can reproduce
the problem if I change it to US Letter.  (same in Fx 3.6 and 4)
Keywords: testcase-wanted
I'm confused by the "testcase-wanted" comment.  I provided a test case; see the
Description.  It's a very simple test case.  What more do you want?

BTW, the bug still exists in 8.0.1.
A minimal testcase that can be attached to this bug.
(In reply to Ryan VanderMeulen from comment #4)
> A minimal testcase that can be attached to this bug.

I still don't know what is wanted.  Do you want me to take this text from the Description above:

> Go to http://www.green960.com/pages/lineup.html
> 
> Click on the first "Print article", just under "listen live". When the Print
> dialogue pops up, select Preview. The first page shown is almost all blank,
> the second page shows the last two programs.
> 
> Now do the same in Safari. (You'll have to select "Open PDF in Preview" from
> the PDF menu.) The first page shows the first five shows, and the second
> page shows the next three.
> 
> (The second "Print article", the one just above "Weekend Programs", works
> fine.)

and put it in a "text" file that I attach to the bug?  I attached the output you get from each when I created this bug.
No, the idea is to attach an html file that reproduces this bug with the minimum amount of code/text needed. The main reason for this is to ensure that this bug can be reproduced even if the original website changes in such a way that it no longer shows the bug.
Just re-tested using recent nightlies, and it turns out this was fixed (on trunk) in the last few days.

Last bad nightly: 2011-12-27
First good nightly: 2011-12-28

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6f4f2e53694b&tochange=b87861e50640

At first glance, I suspect one of Bernd's patches fixed it (at least one relates to table-splitting).
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(er, I meant to resolve as WORKSFORME, until we determine which patch actually fixed it)
Resolution: FIXED → WORKSFORME
> At first glance, I suspect one of Bernd's patches fixed it

(In particular, I suspect the patch for bug 531200 is what fixed this.  I'm doing some targeted builds to confirm.)
Attached file A simple(?) test case.
When I open this attachment in Firefox, and in the Print dialog select Preview, I get two (mainly) blank pages.  When I do the same in Safari (selecting "Open PDF in Preview"), I see the content.
(In reply to Ryan VanderMeulen from comment #7)
> No, the idea is to attach an html file that reproduces this bug with the
> minimum amount of code/text needed. The main reason for this is to ensure
> that this bug can be reproduced even if the original website changes in such
> a way that it no longer shows the bug.

Oh, gosh, I just spent about an hour doing that, and now I see that folks think they know the answer!
It's still useful for confirming that the core issue was the same. Plus it may be useful for an automated regression test (to make sure it doesn't break again). No time spent on QA is wasted time!
Attachment #585097 - Attachment mime type: text/plain → text/html
Yeah -- thanks very much for your work on this, Steve!  It was just coincidental timing that this bug started getting attention just after a fix for it landed from elsewhere. :)  Sorry for any frustration that caused.

As Ryan said, the testcase-reduction is definitely still useful.  If we can get your testcase down to be even smaller (and self-contained -- ideally with no external images/scripts/stylesheets), then a version of it would definitely be useful as an automated regression test.  (No pressure though -- bug 531200 did include a regression test, and that may be similar to what an extremely-reduced version of this bug's testcase would end up looking like).

For the record, I wasn't able to reproduce the bug with your attached testcase, but that's not particularly surprising -- as noted in bug 531200 comment 0, this sort of bug is very dependent on exact system metrics (font/margin sizes etc).  It also looks like the testcase tries to use a script & stylesheet from a file on your local filesystem, and those obviously aren't available to the bugzilla-hosted copy -- that might also explain why it's not reproducing the bug for me.

In any case -- my targeted builds confirmed that bug 531200 (testing with the original URL):
http://hg.mozilla.org/mozilla-central/rev/1f2caed431a0 (bug 531200): WORKS
http://hg.mozilla.org/mozilla-central/rev/ab7997839419 (parent of ^) BROKEN

Resolving as duplicate of that bug.
Depends on: 531200
Resolution: WORKSFORME → DUPLICATE
Duplicate of bug: 531200
(In reply to Daniel Holbert [:dholbert] from comment #14)
> In any case -- my targeted builds confirmed that bug 531200 (testing with
> the original URL):
er I meant "confirmed that bug 531200 _fixed this_"
Also worth pointing out that bug 531200 was fixed for what will be Firefox 12. If you want to confirm that the bug is fixed, you can try with a nightly build from the link below.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/12/2011-12-30-03-11-51-mozilla-central/
(In reply to Daniel Holbert [:dholbert] from comment #14)
> Yeah -- thanks very much for your work on this, Steve!  It was just
> coincidental timing that this bug started getting attention just after a fix
> for it landed from elsewhere. :)  Sorry for any frustration that caused.

Just a bit.  :-)

> For the record, I wasn't able to reproduce the bug with your attached
> testcase, but that's not particularly surprising -- as noted in bug 531200
> comment 0, this sort of bug is very dependent on exact system metrics
> (font/margin sizes etc).  It also looks like the testcase tries to use a
> script & stylesheet from a file on your local filesystem, and those
> obviously aren't available to the bugzilla-hosted copy -- that might also
> explain why it's not reproducing the bug for me.

I'm sorry about that.  I'm not very facile with html.  I'm more used to C.

But you could go try it with the original URL:
http://www.green960.com/pages/lineup.html

It still reproduces the problem for me with 8.0.1.

(In reply to Ryan VanderMeulen from comment #16)
> Also worth pointing out that bug 531200 was fixed for what will be Firefox
> 12. If you want to confirm that the bug is fixed, you can try with a nightly
> build from the link below.
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/12/2011-12-30-03-
> 11-51-mozilla-central/

What's the mac-shark dmg for?  Should I use that one or the ordinary mac.dmg?

(I may not get to trying it until next week.)

Thanks,
--Steve
(In reply to Steve Chessin from comment #17)
> What's the mac-shark dmg for?  Should I use that one or the ordinary mac.dmg?

Ignore the shark build -- use the other one.  (It actually doesn't really matter. The shark builds just have extra instrumentation, to let you connect a profiler and analyze where Firefox is spending its time.  See https://developer.mozilla.org/en/Profiling_JavaScript_with_Shark for more details.)

Also -- you should probably create a new (temporary) Firefox profile and set it as your default profile, before you fire up the nightly build.  This page can help you with that:
 http://support.mozilla.org/en-US/kb/Managing-profiles
(This is just a precaution, to avoid any data loss (e.g. bookmarks/history/addons) from potential differences between how Nightly & Firefox 8.01 store stuff internally)
see http://hg.mozilla.org/mozilla-central/rev/1f2caed431a0 the testcases for a remote image replacement strategy. It replaces the remote image with a data url that creates a red 1px * 1px image which is then resized.

there is no need to create print js call saying that it shows the problem on print preview is good enough
You need to log in before you can comment on or make changes to this bug.