Closed Bug 1308516 Opened 4 years ago Closed 3 years ago

"An error occurred while printing." on GitLab pages when e10s is disabled

Categories

(Core :: Printing: Output, defect)

49 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox53 --- affected
firefox54 --- affected
firefox55 --- affected

People

(Reporter: stbuehler, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

404 bytes, text/html
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce:

- create new profile: no extensions, only "ask to activate" plugins (mozplugger, icedtea)
- open https://gitlab.com/gnutls/gnutls/
- ctrl-p (print)
- select "Print to File" (PDF or PS doesn't matter)
- "Print"
- debian amd64 testing/sid/experimental: firefox (50.0~b1-1) still broken, error is not new


Actual results:

- Shows "Print Preview Error": "An error occurred while printing." error message box
- created empty file (PDF or PS)
- can't find a proper error message anywhere


Expected results:

- Actual PDF / PS with printed content
Print preview actually works (just a little ugly due to gitlab css ****)
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
See Also: → 1308530
Component: Untriaged → Printing: Output
Product: Firefox → Core
I have also reproduced the issue and it Works fine for me also - with Nightly 52.0a1. Try using the latest release version.
So, in which version (numbers) can you reproduce?
(In reply to Marco Castelluccio [:marco] from comment #3)
> So, in which version (numbers) can you reproduce?

Yeah seen the error too using Firefox 49.0.

ni on Loic ,maybe you could help figure out and give ideas?
Flags: needinfo?(epinal99-bugzilla2)
(In reply to Esther Monchari from comment #4)
> ni on Loic ,maybe you could help figure out and give ideas?

All versions of Firefox are affected (even very old ones like FF17). I tried to save the webpage but it's not reproducible locally.

There is an error is the browser console after trying to print:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPrintSettingsService.initPrintSettingsFromPrinter]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/browser-content.js :: getPrintSettings :: line 487"  data: no]  (unknown)
TypeError: printSettings is null[Learn More]


The funny thing is I'm able to print the page if I open the browser console or the developer toolbar (with the same error message).
Flags: needinfo?(epinal99-bugzilla2)
See Also: → 1308394
I'm not sure both issues are connected, the Gitlab page crashes in Nightly with e10s because there is SVG https://gitlab.com/gnutls/gnutls/badges/master/build.svg which is bug 1308394.
Blocks: 1309241
I confirm this exact behavior with Firefox 49.0 on Fedora Linux. Why is this kept as unconfirmed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I found two workarounds:

1. Disable JavaScript
2. Use `Stylish` to insert the following snippet:

  @media print {
    /* fix firefox print internal error */
    html.turbolinks-progress-bar::before {
      display: none !important;
    }
  }

When JavaScript is active, the following CSS is inserted, which seems to be the root cause of the problem:

  html.turbolinks-progress-bar::before {
    content: '';
    position: fixed;
    top: 0;
    left: 0;
    z-index: 2000;
    background-color: #0076ff;
    height: 3px;
    opacity: 0.99;
    width: 0%;
    transition: width 300ms ease-out, opacity 150ms ease-in;
    transform: translate3d(0,0,0);
  }
stbuehler, would you be able to create and attach a simplified testcase of the webpage with the details from your previous comment?
Flags: needinfo?(stbuehler)
Attached file test case
It seems to be a combination of font-face, html::before and a document spanning multiple pages.
Flags: needinfo?(stbuehler)
Thanks for the testcase, indeed I get the same issue when printing. Very old versions of Firefox are affected too.
Keywords: testcase
Duplicate of this bug: 1309241
Hi dbaron,
Can you help shed some light here or find an owner for this?
Flags: needinfo?(dbaron)
No longer blocks: 1309241
See Also: 1308530
See Also: 1308394
Carrying over tracking flags from Bug 1309241.
Flags: needinfo?(dbaron) → needinfo?(bugs)
Clearing the tracking flags per comment 7 (i.e., not a recent regression.)

jwatt: how does this test page look with your PDF patches? I'm inclined to fix it with the SkiaPDF work.
Flags: needinfo?(bugs) → needinfo?(jwatt)
There have been a lot of printing fixes landed recently. I'm not sure which one fixed this bug, but it's fixed in Nightly and in aurora52. It is not fixed in beta unfortunately.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jwatt)
Resolution: --- → WORKSFORME
We could use mozregression to find the fix, if it turns out to be a simple one we might uplift it to 51.
(In reply to Jonathan Watt [:jwatt] from comment #18)
> There have been a lot of printing fixes landed recently. I'm not sure which
> one fixed this bug, but it's fixed in Nightly and in aurora52. It is not
> fixed in beta unfortunately.

Are you sure about that? I think the issue is still here in non-e10s mode.
e10s has never been an issue in this bug.

Disable e10s in Nightly and try with the testcase (https://bugzilla.mozilla.org/attachment.cgi?id=8805073), I'm sure you'll have the error about printing.
Flags: needinfo?(jwatt)
(In reply to Loic from comment #20)
> Are you sure about that? I think the issue is still here in non-e10s mode.
> e10s has never been an issue in this bug.

As, that wasn't clear to me. Yes, I can still repro with e10s disabled.

In that case, to answer Jet's question, no, printing-via-PDF does not fix this bug. But given that e10s fixes it I'm not sure it's worth spending a lot of time debugging. I'll reopen it anyway. I did spend some time debugging this when Jet originally needinfo'ed me but it wasn't a quick fix and I had more pressing things going on.

I'll needinfo bobowen for a second opinion since he fixed another bug with similar symptoms where printSettings wasn't available in some way.
Status: RESOLVED → REOPENED
Flags: needinfo?(jwatt) → needinfo?(bobowencode)
Resolution: WORKSFORME → ---
Summary: "An error occurred while printing." on GitLab pages → "An error occurred while printing." on GitLab pages when e10s is disabled
(In reply to stbuehler from comment #10)
> I found two workarounds:

By the way, nice work on the debugging!
On Windows (non-e10s) the test case is failing because the nsIPageSequenceFrame (first obtained at [1]), has already been destroyed, by the time we get to [2] and then [3] where we fail.

It doesn't appear to be to do with print settings (at least on Windows).

The destruction seems to happen during some sort of restyle:
nsWeakFrame::Clear Line 3826
mozilla::PresShell::ClearFrameRefs Line 2932
nsFrame::DestroyFrom Line 732
nsSplittableFrame::DestroyFrom Line 40
nsContainerFrame::DestroyFrom Line 246
nsIFrame::Destroy Line 587
nsContainerFrame::RemoveFrame Line 174
mozilla::ViewportFrame::RemoveFrame Line 197
nsFrameManager::RemoveFrame Line 509
nsCSSFrameConstructor::ContentRemoved Line 8558
nsCSSFrameConstructor::RecreateFramesForContent Line 9745
nsCSSFrameConstructor::RecreateFramesForContent Line 9679
mozilla::RestyleManagerBase::ProcessRestyledFrames Line 1184
mozilla::RestyleManager::ComputeAndProcessStyleChange Line 3806
mozilla::RestyleManager::StartRebuildAllStyleData Line 765
mozilla::RestyleManager::BeginProcessingRestyles Line 872
mozilla::RestyleTracker::DoProcessRestyles Line 156
mozilla::RestyleManager::ProcessRestyles Line 490
mozilla::RestyleManager::ProcessPendingRestyles Line 835
mozilla::PresShell::FlushPendingNotifications Line 4097
nsRefreshDriver::Tick Line 1837

I don't know much about the layout code and this doesn't happen in the e10s case for some reason.
Does this behaviour make any sense to you?

[1] https://hg.mozilla.org/mozilla-central/file/de67fccc4c64/layout/printing/nsPrintEngine.cpp#l2402
[2] https://hg.mozilla.org/mozilla-central/file/de67fccc4c64/layout/printing/nsPrintEngine.cpp#l2629
[3] https://hg.mozilla.org/mozilla-central/file/de67fccc4c64/layout/printing/nsPrintEngine.cpp#l2668
Flags: needinfo?(bobowencode) → needinfo?(jwatt)
(In reply to Jonathan Watt [:jwatt] from comment #22)
> (In reply to stbuehler from comment #10)
> > I found two workarounds:
> 
> By the way, nice work on the debugging!

Thanks :)

(In reply to Bob Owen (:bobowen) from comment #23)
> On Windows (non-e10s) the test case is failing because the
> nsIPageSequenceFrame (first obtained at [1]), has already been destroyed, by
> the time we get to [2] and then [3] where we fail.
> 
> It doesn't appear to be to do with print settings (at least on Windows).
> 
> The destruction seems to happen during some sort of restyle:
> nsWeakFrame::Clear Line 3826
> mozilla::PresShell::ClearFrameRefs Line 2932
> nsFrame::DestroyFrom Line 732
> nsSplittableFrame::DestroyFrom Line 40
> nsContainerFrame::DestroyFrom Line 246
> nsIFrame::Destroy Line 587
> nsContainerFrame::RemoveFrame Line 174
> mozilla::ViewportFrame::RemoveFrame Line 197
> nsFrameManager::RemoveFrame Line 509
> nsCSSFrameConstructor::ContentRemoved Line 8558
> nsCSSFrameConstructor::RecreateFramesForContent Line 9745
> nsCSSFrameConstructor::RecreateFramesForContent Line 9679
> mozilla::RestyleManagerBase::ProcessRestyledFrames Line 1184
> mozilla::RestyleManager::ComputeAndProcessStyleChange Line 3806
> mozilla::RestyleManager::StartRebuildAllStyleData Line 765
> mozilla::RestyleManager::BeginProcessingRestyles Line 872
> mozilla::RestyleTracker::DoProcessRestyles Line 156
> mozilla::RestyleManager::ProcessRestyles Line 490
> mozilla::RestyleManager::ProcessPendingRestyles Line 835
> mozilla::PresShell::FlushPendingNotifications Line 4097
> nsRefreshDriver::Tick Line 1837
> 
> I don't know much about the layout code and this doesn't happen in the e10s
> case for some reason.
> Does this behaviour make any sense to you?

Thanks for your pointers (I think "nsCSSFrameConstructor::ContentRemoved" is the one destroying the page sequence); I now installed debug symbols (for debian unstable) and got a similar backtrace:

#0  nsCSSFrameConstructor::ContentRemoved (this=this@entry=0x7fe0677ae420, aContainer=0x0, aChild=aChild@entry=0x7fe067a41870, aOldNextSibling=0x0, aFlags=nsCSSFrameConstructor::REMOVE_FOR_RECONSTRUCTION, 
    aDidReconstruct=aDidReconstruct@entry=0x7ffd1e004de3, aDestroyedFramesFor=0x0) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsCSSFrameConstructor.cpp:8143
#1  0x00007fe088cbe0d4 in nsCSSFrameConstructor::RecreateFramesForContent (this=this@entry=0x7fe0677ae420, aContent=<optimized out>, aAsyncInsert=<optimized out>, aFlags=nsCSSFrameConstructor::REMOVE_FOR_RECONSTRUCTION, 
    aDestroyedFramesFor=0x0) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsCSSFrameConstructor.cpp:9597
#2  0x00007fe088cbdffe in nsCSSFrameConstructor::RecreateFramesForContent (this=0x7fe0677ae420, aContent=0x7fe066ebf680, aAsyncInsert=aAsyncInsert@entry=false, aFlags=aFlags@entry=nsCSSFrameConstructor::REMOVE_FOR_RECONSTRUCTION, 
    aDestroyedFramesFor=aDestroyedFramesFor@entry=0x0) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsCSSFrameConstructor.cpp:9553
#3  0x00007fe088cbe3f0 in mozilla::RestyleManager::ProcessRestyledFrames (this=this@entry=0x7fe0658d9ba0, aChangeList=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/RestyleManager.cpp:842
#4  0x00007fe088cbe8c7 in mozilla::RestyleManager::ComputeAndProcessStyleChange (this=this@entry=0x7fe0658d9ba0, aFrame=aFrame@entry=0x7fe05ea31a78, 
    aMinChange=aMinChange@entry=(nsChangeHint_RepaintFrame | nsChangeHint_NeedReflow | nsChangeHint_ClearAncestorIntrinsics | nsChangeHint_ClearDescendantIntrinsics | nsChangeHint_NeedDirtyReflow | nsChangeHint_SyncFrameView | nsChangeHint_SchedulePaint | nsChangeHint_ReflowChangesSizeOrPosition), aRestyleTracker=..., aRestyleHint=aRestyleHint@entry=eRestyle_ForceDescendants, aRestyleHintData=...)
    at /build/firefox-1vPO32/firefox-50.1.0/layout/base/RestyleManager.cpp:4948
#5  0x00007fe088cbe9fb in mozilla::RestyleManager::StartRebuildAllStyleData (this=0x7fe0658d9ba0, aRestyleTracker=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/RestyleManager.cpp:1681
#6  0x00007fe088cbea73 in mozilla::RestyleManager::BeginProcessingRestyles (this=<optimized out>, aRestyleTracker=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/RestyleManager.cpp:1786
#7  0x00007fe088cc06de in mozilla::RestyleTracker::DoProcessRestyles (this=this@entry=0x7fe0658d9bf8) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/RestyleTracker.cpp:153
#8  0x00007fe088cc0ed7 in mozilla::RestyleManager::ProcessRestyles (this=this@entry=0x7fe0658d9ba0, aRestyleTracker=...) at /build/firefox-1vPO32/firefox-50.1.0/build-browser/dist/include/mozilla/RestyleManager.h:513
#9  0x00007fe088cc102a in mozilla::RestyleManager::ProcessPendingRestyles (this=0x7fe0658d9ba0) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/RestyleManager.cpp:1749
#10 0x00007fe088d03039 in mozilla::RestyleManagerHandle::Ptr::ProcessPendingRestyles (this=<optimized out>) at /build/firefox-1vPO32/firefox-50.1.0/build-browser/dist/include/mozilla/RestyleManagerHandleInlines.h:74
#11 PresShell::FlushPendingNotifications (this=0x7fe0663dd400, aFlush=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsPresShell.cpp:4113
#12 0x00007fe088c70a77 in nsRefreshDriver::Tick (this=0x7fe0663dd000, aNowEpoch=aNowEpoch@entry=1484328671493861, aNowTime=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsRefreshDriver.cpp:1750
#13 0x00007fe088c7142d in mozilla::RefreshDriverTimer::TickDriver (driver=<optimized out>, jsnow=jsnow@entry=1484328671493861, now=..., now@entry=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsRefreshDriver.cpp:279
#14 0x00007fe088c7155b in mozilla::RefreshDriverTimer::TickRefreshDrivers (aJsNow=aJsNow@entry=1484328671493861, aNow=aNow@entry=..., aDrivers=..., this=0x7fe06df371f0)
    at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsRefreshDriver.cpp:251
#15 0x00007fe088c71617 in mozilla::RefreshDriverTimer::Tick (this=0x7fe06df371f0, jsnow=1484328671493861, now=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsRefreshDriver.cpp:270
#16 0x00007fe088c71821 in mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers (aTimeStamp=..., this=0x7fe06df371f0) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsRefreshDriver.cpp:593
#17 mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver (this=<optimized out>, aVsyncTimestamp=...) at /build/firefox-1vPO32/firefox-50.1.0/layout/base/nsRefreshDriver.cpp:513
#18 0x00007fe088c6b7b1 in mozilla::detail::RunnableMethodArguments<mozilla::TimeStamp>::applyImpl<mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver, void (mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp), StoreCopyPassByValue<mozilla::TimeStamp>, 0ul> (args=..., m=<optimized out>, o=<optimized out>) at /build/firefox-1vPO32/firefox-50.1.0/build-browser/dist/include/nsThreadUtils.h:729
#19 mozilla::detail::RunnableMethodArguments<mozilla::TimeStamp>::apply<mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver, void (mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp)> (
    m=<optimized out>, o=<optimized out>, this=<optimized out>) at /build/firefox-1vPO32/firefox-50.1.0/build-browser/dist/include/nsThreadUtils.h:736
#20 mozilla::detail::RunnableMethodImpl<void (mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp), true, false, mozilla::TimeStamp>::Run (this=<optimized out>)
    at /build/firefox-1vPO32/firefox-50.1.0/build-browser/dist/include/nsThreadUtils.h:764
#21 0x00007fe0876de707 in nsThread::ProcessNextEvent (this=0x7fe094462f80, aMayWait=<optimized out>, aResult=0x7ffd1e006847) at /build/firefox-1vPO32/firefox-50.1.0/xpcom/threads/nsThread.cpp:1076
#22 0x00007fe0876f9775 in NS_ProcessNextEvent (aThread=<optimized out>, aThread@entry=0x7fe094462f80, aMayWait=aMayWait@entry=false) at /build/firefox-1vPO32/firefox-50.1.0/xpcom/glue/nsThreadUtils.cpp:290
#23 0x00007fe0879b35f0 in mozilla::ipc::MessagePump::Run (this=0x7fe083059500, aDelegate=0x7fe0944929f0) at /build/firefox-1vPO32/firefox-50.1.0/ipc/glue/MessagePump.cpp:100
#24 0x00007fe0879a3018 in MessageLoop::RunHandler (this=<optimized out>) at /build/firefox-1vPO32/firefox-50.1.0/ipc/chromium/src/base/message_loop.cc:225
#25 MessageLoop::Run (this=<optimized out>) at /build/firefox-1vPO32/firefox-50.1.0/ipc/chromium/src/base/message_loop.cc:205
#26 0x00007fe088b17aa0 in nsBaseAppShell::Run (this=0x7fe079b08b00) at /build/firefox-1vPO32/firefox-50.1.0/widget/nsBaseAppShell.cpp:156
#27 0x00007fe08916bf84 in nsAppStartup::Run (this=0x7fe079b04060) at /build/firefox-1vPO32/firefox-50.1.0/toolkit/components/startup/nsAppStartup.cpp:284
#28 0x00007fe0891b1f54 in XREMain::XRE_mainRun (this=this@entry=0x7ffd1e006ae8) at /build/firefox-1vPO32/firefox-50.1.0/toolkit/xre/nsAppRunner.cpp:4297
#29 0x00007fe0891b2229 in XREMain::XRE_main (this=this@entry=0x7ffd1e006ae8, argc=argc@entry=4, argv=argv@entry=0x7ffd1e007ec8, aAppData=aAppData@entry=0x7ffd1e006ce8)
    at /build/firefox-1vPO32/firefox-50.1.0/toolkit/xre/nsAppRunner.cpp:4424
#30 0x00007fe0891b248b in XRE_main (argc=4, argv=0x7ffd1e007ec8, aAppData=0x7ffd1e006ce8, aFlags=<optimized out>) at /build/firefox-1vPO32/firefox-50.1.0/toolkit/xre/nsAppRunner.cpp:4515
#31 0x00005595032854bf in do_main (argc=4, argv=0x7ffd1e007ec8, envp=<optimized out>, xreDirectory=0x7fe09446f9c0) at /build/firefox-1vPO32/firefox-50.1.0/browser/app/nsBrowserApp.cpp:247
#32 0x0000559503284a77 in main (argc=4, argv=0x7ffd1e007ec8, envp=0x7ffd1e007ef0) at /build/firefox-1vPO32/firefox-50.1.0/browser/app/nsBrowserApp.cpp:380

It seems VsyncRefreshDriverTimer::RunRefreshDrivers triggers a
refresh on the page to be printed, which causes all the problems.
And indeed the following line in gdb "fixed" printing the
testcase (basically inserting a 'retq' at the beginning of the
function):

    set *(unsigned char*)('mozilla::RefreshDriverTimer::Tick') = 0xc3
We've built 51 RC. This is too late for 51. Mark 51 won't fix.
I think this was possibly fixed by bug 1329220. Does someone else want to confirm that?
Flags: needinfo?(jwatt)
(In reply to Jonathan Watt [:jwatt] from comment #26)
> I think this was possibly fixed by bug 1329220. Does someone else want to
> confirm that?

Still not fixed for me with the latest Nightly on Win 7 and e10s disabled.
firefox 52 just landed in debian unstable (as 52-0.1). It is still broken.

Can someone please update the tracking flags (which seem to claim this is fixed in 52 and 53)?
Mass wontfix for bugs affecting firefox 52.
It seems this actually is fixed in firefox 56; not sure about 53-55.
(In reply to stbuehler from comment #30)
> It seems this actually is fixed in firefox 56; not sure about 53-55.

I'd guess it works in 56 because that's the release for which e10s was enabled. At any rate, since e10s is now enabled and disabling it is no longer supported I guess this is WONTFIX.
Status: REOPENED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.