Crash in [@ nsPrintJob::ReconstructAndReflow]
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | fixed |
People
(Reporter: u608768, Assigned: emilio)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(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: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=138e7b575614cbfc1e45576a15825f51cb6e6614&tochange=1415430432706ec6b8c7590cda9b8ca87397e7a7.
Erik, could this have been bug 1654406?
Comment 1•5 years ago
|
||
Emilio, did you land the resource loading changes already?
Comment 2•5 years ago
•
|
||
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?
(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: https://crash-stats.mozilla.org/signature/?signature=nsPrintJob%3A%3AReconstructAndReflow&date=%3E%3D2020-07-17T21%3A50%3A00.000Z&date=%3C2020-07-24T21%3A50%3A00.000Z&_sort=-date
Assignee | ||
Comment 4•5 years ago
|
||
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.
Assignee | ||
Comment 5•5 years ago
|
||
I found a repro for bug 1652967, but not for this one ;(
Assignee | ||
Comment 6•5 years ago
|
||
Ok, I can repro this consistently if I print https://mathiasbynens.be/demo/img-loading-lazy with print.always_print_silent=true
. That works for me as a repro. Example crash: bp-a1760bf3-1456-4a65-824c-679e10200725
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
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
document.
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.
Comment 9•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Description
•