Some sites print blank pages or print the first page only with add-on Adblock Plus

REOPENED
Unassigned

Status

()

defect
REOPENED
6 years ago
8 months ago

People

(Reporter: email2sts, Unassigned, NeedInfo)

Tracking

({regression})

18 Branch
mozilla25
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox21 wontfix, firefox22- wontfix, firefox23- wontfix, firefox24-)

Details

Attachments

(1 attachment, 2 obsolete attachments)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

Went to this site:
http://www.guardian.co.uk/world/2013/jun/06/us-tech-giants-nsa-data/print
clicked Print under FireFox 21.0 File menu, then clicked Print on the OS X printer control popup
Am running OS X 10.6.8


Actual results:

All pages printed blank except for a header (which was what was expected (article title and URL) and a footer with page number and time and date of printing. The first page also had the newspaper's logo and a copyright notice.


Expected results:

The article itself should have printed out.  The website invites printing out pages and provides pages for printing that are free of clutter.  My monitor displayed both the original page and the printer friendly page properly.  The original cluttered page didn't print either, except the header and footer described above.

Thank you very much for your superb browser! I've been using FireFox since 2006.
Adblock Plus issue, try in safe mode (or with this add-on disabled), it should work normally.
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
Blocks: abp
Component: Untriaged → Printing: Output
Product: Firefox → Core
Summary: Some sites print blank pages or print the first page only → Some sites print blank pages or print the first page only with add-on Adblock Plus
Same issue in print preview with ABP enabled.
Thank you very much, Loic; you have solved the problem!

Turning Adblock Plus off for only that page didn't help.  But when I turned Adblock Plus off completely, both Mac Preview's "print preview" and FireFox's "print" worked perfectly.

I sure do appreciate your help!
Durk
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Thank you very much! Works perfectly with Adblock Plus turned off completely.
Reopened since this behavior isn't very normal.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I can confirm this issue for Linux x64 with Adblock Plus 2.2.5a.3660 devbuild. The reason for this behavior seems to be the global stylesheet registered by Adblock Plus (turning Adblock Plus off immediately "fixes" the issue without reloading the page) even though I don't quite see how. The same global stylesheet is applied to the displayed page but doesn't affect it negatively.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
STR:
1) Create a new profile
2) Install ABP https://addons.mozilla.org/en-us/firefox/addon/adblock-plus/
3) Go to http://www.guardian.co.uk/world/2013/jun/06/us-tech-giants-nsa-data/print
4) Print preview

Result: print preview is almost completely blank (header/footer are still present)
Disable ABP everywhere make the content appear.

Regression range:
m-c
good=2012-09-20
bad=2012-09-21
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1e56d3016820&tochange=48c4938eaf57

Maybe bug 468568 but not sure.
Version: 21 Branch → 18 Branch
You should allow the following address/filter.
##.hide-on-popup  guardian.co.uk##.hide-on-popup
Last Good: d7a64a002069
First Bad: 84317c2f199c
Regressed by:
84317c2f199c	Julian Viereck — Bug 468568. Main patch: support downloading fonts in printing and print preview. r=smaug
Depends on: 468568
We'd take a low risk uplift, but not critical enough to track.
(In reply to Alice0775 White from comment #8)
> You should allow the following address/filter.
> ##.hide-on-popup  guardian.co.uk##.hide-on-popup

Alice, what did you mean by this?
Flags: needinfo?(alice0775)
The weird thing is that when you print preview, the content actually appears for a moment and then disappears!
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #11)
> (In reply to Alice0775 White from comment #8)
> > You should allow the following address/filter.
> > ##.hide-on-popup  guardian.co.uk##.hide-on-popup
> 
> Alice, what did you mean by this?

(to alloe guardian.co.uk##.hide-on-popup)
1. Click ABP icon
2. Click red "x" in row "##.hide-on-popup"
Flags: needinfo?(alice0775)
Err
s/1. Click ABP icon/1. Click ABP icon and select "Open blockable items"( Ctrl+Shit+V) /
When we do print preview, we end up permanently in a state where a whole lot of frames are dirty and reflow hasn't happened, so most of the frames are size 0,0.
Frame state looks like this:

    SimplePageSequence(html)(-1)@0x7f76878ed6c8 {0,-3840,98080,691200} [state=0000004000000010] [content=0x7f7688cec3d0] [sc=0x7f76922fc020:-moz-scrolled-page-sequence]<
      Page(-1)@0x7f76922fc728 next=0x7f7693f152a8 next-in-flow=0x7f7693f152a8 {1440,720,48960,63360} vis-overflow=-340,-340,50240,64640 scr-overflow=0,0,48960,63360 [state=0000024000001010] [sc=0x7f76922fc4d0:-moz-page]<
        PageContent(-1)@0x7f76922fccc0 next-in-flow=0x7f7693f15328 {2880,2880,43200,57600} [state=0000006000001200] [sc=0x7f76922fca68:-moz-pagecontent]<

NS_FRAME_HAS_DIRTY_CHILDREN is 0x1000, so the nsPageFrame has that bit set, but nsSimplePageSequence does not. That's wrong.
We hit this in nsSimplePageSequence:

  // Don't do incremental reflow until we've taught tables how to do
  // it right in paginated mode.
  if (!(GetStateBits() & NS_FRAME_FIRST_REFLOW)) {
    // Return our desired size
    SetDesiredSize(aDesiredSize, aReflowState, mSize.width, mSize.height);
    aDesiredSize.SetOverflowAreasToDesiredBounds();
    FinishAndStoreOverflow(&aDesiredSize);
    return NS_OK;
The reflow is caused by AdBlock loading an XBL document async via HitRegistrationChannel.asyncOpen. The XBL binding binds to some element in the print-preview document clone, reconstructing frames for that element and scheduling the reflow that never happens.

Maybe the way to solve stuff like this is to promote reflow change hints in print presentations to reconstructs of the entire frame tree.
Posted patch fix (obsolete) — Splinter Review
I don't like this very much but I think it's the right thing to do (short of fixing incremental reflow of paginated tables).

The DumpFrameTree change is because my version of gdb can't find the static method to call. Adding virtual helped. I think removing the parameter makes sense anyway.
Attachment #762063 - Flags: review?(matspal)
Comment on attachment 762063 [details] [diff] [review]
fix

Seems like a reasonable wallpaper for now.  r=mats

Is the change to layout/style/nsAnimationManager.cpp necessary?
(remove it of not)

Please land the DumpFrameTree change as a separate cset for clarity.

Also, I wonder if "virtual" is sufficient there in general.
I know that using frame->List(...) in gdb doesn't work even though
List() is virtual (and even have overriding methods) but clang on
Linux64 removes it anyway.  __attribute__((used)) might be a better
way to solve that problem.  But I agree that removing the argument
is an improvement anyway.
Attachment #762063 - Flags: review?(matspal) → review+
(In reply to Mats Palmgren [:mats] from comment #20)
> I know that using frame->List(...) in gdb doesn't work even though

frame->List() always works for me in gdb.
Oh, OK.  Upon closer inspection it seems the symbol is there, but:
(gdb) p this->List(stdout, 0, 0)
Cannot resolve method ViewportFrame::List to any overloaded instance
(gdb) p stdout
$4 = -149335424

I guess I should use something else than "stdout" then... what do you use?
On linux frame->List((FILE*)stdout,0,0) works for me, on mac frame->List((FILE*)__stdoutp,0,0).
(gdb) p this
$1 = (ViewportFrame *) 0x7fffc304b420
(gdb) p this->List((FILE*)stdout,0,0)

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6e42791 in fputs () from /lib/x86_64-linux-gnu/libc.so.6
...

Maybe my gdb is just buggy :-)
I think crashing when calling List has happened rarely for me, but it usually works.
https://hg.mozilla.org/mozilla-central/rev/5c044f3a5587
https://hg.mozilla.org/mozilla-central/rev/775a172255b1
Assignee: nobody → robert
Status: NEW → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Depends on: 886295
I think we should back this out to fix bug 886295. Basically, nsSimplePageSequenceFrame is extremely stateful and recreating it after a StartPrint call makes everything break. Moving the state in nsSimplePageSequenceFrame somewhere else would be a good idea, but it's quite a lot of work and we won't want to do it on Aurora anyway.

I think for now we should just leave the core bug unfixed. We just don't support dynamic changes to a document that's being printed or in print preview; fixing that is a ton of work for very little win. However, we might be able to work around the worst effects of this bug by stopping the XBL attach from destroying our frame tree.
Depends on: 891125
Depends on: 892960
Backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
A better approach to fixing this bug. Sync-loading the XBL forces the XBL load to happen before reflowing the document, so we don't try to reflow more than once (which printing can't handle).
Assignee: robert → roc
Attachment #781455 - Flags: review?(mrbkap)
Comment on attachment 781455 [details] [diff] [review]
sync-load XBL for static documents

This can cause us to sync load http resources, which we really want to avoid. Can we limit this to chrome bindings only (given that we turned off remote XBL, that should probably fix all common occurrences of this bug)?
Attachment #781455 - Flags: review?(mrbkap)
As far as I know, XBL can only be attached to static documents when we print, and even then it's rare since we can't print XUL, and content documents can't attach their own XBL, so it basically has to be an extension or UA stylesheet attaching the XBL. Of those, only an extension could load the stylesheet via HTTP.

(In reply to Blake Kaplan (:mrbkap) from comment #32)
> This can cause us to sync load http resources, which we really want to
> avoid. Can we limit this to chrome bindings only (given that we turned off
> remote XBL, that should probably fix all common occurrences of this bug)?

What exactly do you mean by "chrome bindings"? You mean where the URL of the bindings document is a chrome URL, i.e. checking IsSystemOrChromeURLPrincipal? That should work, yes.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #33)
> What exactly do you mean by "chrome bindings"? You mean where the URL of the
> bindings document is a chrome URL, i.e. checking
> IsSystemOrChromeURLPrincipal? That should work, yes.

Yeah, that's what I meant.
Attachment #762063 - Attachment is obsolete: true
Attachment #781455 - Attachment is obsolete: true
Attachment #783385 - Flags: review?(mrbkap)
Comment on attachment 783385 [details] [diff] [review]
URL type check

Thanks.
Attachment #783385 - Flags: review?(mrbkap) → review+
https://hg.mozilla.org/mozilla-central/rev/9435e3497e30
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Comment on attachment 783385 [details] [diff] [review]
URL type check

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 468568
User impact if declined: Some pages won't print when AdBlock is enabled
Testing completed (on m-c, etc.): Landed for a while
Risk to taking this patch (and alternatives if risky): We ended up going with a low-risk approach; a narrowly targeted fix that clearly only affects printing and can only be triggered by addons
String or IDL/UUID changes made by this patch: none
Attachment #783385 - Flags: approval-mozilla-beta?
Attachment #783385 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
> All pages printed blank except for a header (which was what was expected (article title and URL) and a > footer with page number and time and date of printing. The first page also had the newspaper's logo and > a copyright notice.

This is still reproducing on FF 25b2 using Windows 7x64 and Ubuntu 13.04 x86.

Works as expected on Latest Nightly 27 using OS's mentioned above. All pages contents are printed as expected.
Keywords: verifyme
Roc, it seems like this is still reproducible in Firefox 25b2 (see comment 41).
Status: RESOLVED → REOPENED
Flags: needinfo?(roc)
Resolution: FIXED → ---
I don't understand. Mihai, can you find a fix range?
Flags: needinfo?(roc) → needinfo?(mihai.morar)
I now have the latest version of Firefox 24.0 with the latest plugin updates.  Still running OS X 10.6.8
Problem unchanged.  Behavior exactly the same as before.  Turning off Adblock Plus everywhere allows printing as expected.  Turning Adblock Plus off only on that page or only on that website doesn't help.  

Turning Adblock Plus off everywhere when I want to print something from this website is not a hassle, but I thought that you might want to know that this anomalous behavior hasn't been fixed for Firefox 24.0 even though the tracking flag says fixed. (I won't attempt to change the flag, though.)
Thank you all for your dedicated work.  I love Firefox!
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #43)
> I don't understand. Mihai, can you find a fix range?

Looking closer to this issue I am able to reproduce it even on latest nightly. I think I had adblock disabled while testing yesterday on 27 builds because now I able to reproduce this issue in 100% cases using Latest Nightly mentioned in Comment 41.

I am also able to reproduce this issue on builds before and immediately after the fix in Comment 38 so I think this problem was never fixed.
Flags: needinfo?(mihai.morar)
:-(
I wonder if Adblock Plus changed, maybe?
I am using Adblock Plus 2.3.2 
Durk can you provide which verion of Adblock Plus are you using now and if you remember which version were you using in Comment 0 ?

Here are all Adblock Plus versions available:
https://addons.mozilla.org/en-us/firefox/addon/adblock-plus/versions/
Flags: needinfo?(email2sts)
No, there were no relevant changes in Adblock Plus - the code registering a global stylesheet hasn't changed in ages. If anything, the filters might have changed. However, the filter mentioned in comment 8 is still part of EasyList.
Flags: needinfo?(email2sts)
I've just verified that "guardian.co.uk##.hide-on-popup" is still the filter causing the issue in the current Firefox nightly. That filter is translated into a global CSS rule @-moz-document domain(guardian.co.uk) { ##.hide-on-popup { -moz-binding: url(...); } }. The binding this refers to is invalid (binding source is <bindings xmlns='http://www.mozilla.org/xbl'/>) which normally causes the element to be hidden.
I installed FireFox 21.0 (20130511120893) on May 17, 7:41:47 PM and updated any plugin that needed updating at that time, including Adblock Plus.

I installed FireFox 24.0 (20130910160258) on September 18, 10:17"52 AM and updated any plugin that needed updating at that time, including Adblock Plus.

I have not been able to figure out how to find the version of Adblock Plus that I am now using. If you tell me what to do, I will do so.  Is there a folder on my computer that has a change log for FireFox plugins?

I checked the Adblock Plus version history page that you provided. I should currently be running the latest version 2.3.2.  

When I installed FireFox 21.0, it would have had Adbolck Plus 2.2.4 as of that date, and that still would have been the latest version when I reported the problem on June 7. 

If there is anything further that I can do to help, just let me know.  Following this process has been fascinating.
I see this happening on Microsoft Knowledge Base article I try to print. In both SM 2.23 and Fx 27.0b6, there are blank pages. Yes, even in Safe Mode with add on s disabled. It seems worse, however, in SM than if Fx. As an example, visit: http://goo.gl/f28lXD and do a Print Preview in SM.
Mihai, can you confirm comment 51 is reproducible?
Flags: needinfo?(mihai.morar)
QA Contact: mihai.morar
Tested on Firefox 27 betas 6 and 7 with no add-ons:
Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0

When printing (or print preview), the second page looks fine, same as for other browsers. The first page is three quarters empty. It contains the start of the text at the end of the page. The rest of the text that should be on the first page is nowhere.
Flags: needinfo?(mihai.morar)
(In reply to Arthur K. from comment #51)
> I see this happening on Microsoft Knowledge Base article I try to print. In
> both SM 2.23 and Fx 27.0b6, there are blank pages. Yes, even in Safe Mode
> with add on s disabled. It seems worse, however, in SM than if Fx. As an
> example, visit: http://goo.gl/f28lXD and do a Print Preview in SM.

I don't know why you reported your issue in this bug report. This bug is about Firefox printing blank pages when the add-on Adblock Plus is enabled. That's not your case because the webpages of your example are still printed blank in safe mode or with a new profile.

Please, file a new bug.
I truly don't mean to make churn or noise but I can't file a new bug because a bug like this was filed back in 2007 (see bug 386569) and because it's been an ongoing problem to which one is giving any serious attention. I do have AdBlock Plus installed on both my Firefox and Seamonkey installs so I still feel it has relevance to be here to keep attention focused on the problem: printing is in need of some major TLC. There are bug reports dating back years with this issue (http://goo.gl/xEijoC).
This bug is still alive.  Printing behavior is still exactly as I originally reported; blank pages are printed for that URL unless I turn off AddBlock Plus everywhere.  Turning it off for the Guardian web site only doesn't restore printing.

I am now running FireFox 26.0 under OS X 10.6.8 (10K549) with all the latest updates.

The workaround is easy, but I thought that you ought to know that the bug hasn't been fixed as of FireFox 26.0.  It wasn't fixed with FireFox 24.0 or 25.0 either.

Thank yo very much for FireFox!
I can no longer reproduce this issue with Firefox 47.0.1 and Adblock Plus 2.7.3 on OS X 10.11. This could be because the issue is indeed fixed or because the Guardian website changed. Does anybody still see this issue?
(In reply to Wladimir Palant from comment #57)
> I can no longer reproduce this issue with Firefox 47.0.1 and Adblock Plus
> 2.7.3 on OS X 10.11. This could be because the issue is indeed fixed or
> because the Guardian website changed. Does anybody still see this issue?

I'm no longer seeing it on SM or FX either.
Durk, if you are here, are you still seeing the issue?
Flags: needinfo?(email2sts)
For URL https://www.nineproductions.com/solaris-11-samba-zfs-configuration/

Firefox 64.0 and Firefox 60.x ESR only display first page in print preview window.
I run Firefox with the uBlock Origin extension.

I have seen this same issue on other URLs.

Chrome has no problems displaying all pages.
You need to log in before you can comment on or make changes to this bug.