Closed Bug 1655179 Opened 4 years ago Closed 4 years ago

Crash in [@ nsPrintJob::ReconstructAndReflow]


(Core :: Layout, defect)

Windows 7



Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 --- fixed


(Reporter: u608768, Assigned: emilio)




(Keywords: crash, regression)

Crash Data


(1 file)

This bug is for crash report bp-007b6781-d2de-46bd-ac33-c505f0200724.

Top 10 frames of crashing thread:

0 xul.dll nsPrintJob::ReconstructAndReflow layout/printing/nsPrintJob.cpp:1380
1 xul.dll nsPrintJob::SetupToPrintContent layout/printing/nsPrintJob.cpp:1469
2 xul.dll nsPrintJob::MaybeResumePrintAfterResourcesLoaded layout/printing/nsPrintJob.cpp:1733
3 xul.dll nsPrintJob::OnStateChange layout/printing/nsPrintJob.cpp:1756
4 xul.dll nsDocLoader::DoFireOnStateChange uriloader/base/nsDocLoader.cpp:1331
5 xul.dll nsDocLoader::FireOnStateChange uriloader/base/nsDocLoader.cpp:1294
6 xul.dll nsDocLoader::doStopURLLoad uriloader/base/nsDocLoader.cpp:898
7 xul.dll nsDocLoader::OnStopRequest uriloader/base/nsDocLoader.cpp:622
8 xul.dll mozilla::net::nsLoadGroup::NotifyRemovalObservers netwerk/base/nsLoadGroup.cpp:615
9 xul.dll mozilla::net::nsLoadGroup::RemoveRequest netwerk/base/nsLoadGroup.cpp:522

Started in build 20200723095657. Regression window:

Erik, could this have been bug 1654406?

Flags: needinfo?(enordin)

Emilio, did you land the resource loading changes already?

Component: DOM: Core & HTML → Layout
Flags: needinfo?(emilio)

It's certainly possible that my patch could have caused this, but my changes should have been pretty self contained to the "Print Selection Only" option. If this is happening during any other use case then it may not be my patch.

I've been trying to reproduce this on my end, unsuccessfully so far. I will keep trying.

Does this happen only on Windows 7?

Flags: needinfo?(enordin)

(In reply to Erik Nordin [:nordzilla] from comment #2)

Does this happen only on Windows 7?

Mostly Windows 7, but a few Windows 10 crashes too:

Yeah this smells a lot like something bug 1648064 could've made much more common. The code path is pre-existing, but before we were only using it for font loads and now we also use it for images.

Will poke.

I found a repro for bug 1652967, but not for this one ;(

See Also: → 1652967

Ok, I can repro this consistently if I print with print.always_print_silent=true. That works for me as a repro. Example crash: bp-a1760bf3-1456-4a65-824c-679e10200725

Assignee: nobody → emilio
Regressed by: 1648064
No longer regressed by: 1654406
Has Regression Range: --- → yes
Flags: needinfo?(emilio)

This is afaict a pre-existing (conceptual) issue before my patch, but
it was only theoretical because @font-face loads are triggered from
styling / layout, so we wouldn't trigger them until we initialize the

The print setup may be asynchronous
(via nsPrintJob::Observe -> InitPrintDocConstruction -> ReflowDocList).

If we get the load event sooner than that, then we'd try to start
printing before we've ever called ReflowDocList which is what sets
everything up.

Thus we'd assert in debug builds here:

And crash in ReconstructAndReflow in release builds.

We don't care about what goes on before we start setting up the
presentation of the document, so defer setting up the
web-progress-listener until we do that.

Pushed by
Don't attach a progress listener until we've started to set up the print presentation. r=smaug
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
You need to log in before you can comment on or make changes to this bug.