Current tab crashes when printing an iframe with "break-inside: avoid"
Categories
(Core :: Print Preview, defect)
Tracking
()
People
(Reporter: tspradli, Assigned: jfkthame)
References
(Regression)
Details
(Keywords: regression)
Attachments
(6 files)
|
8.22 KB,
text/html
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-esr128+
|
Details | Review |
Steps to reproduce:
Printing an iframe with sections using break-inside: avoid. Commenting/uncommenting the last paragraph seems to enable/disable the issue, so it appears to be related to the view port dimensions and width of content.
This was first identified using https://github.com/futurepress/epub.js to view epubs, so the page width and column widths are set in a similar fashion. The iframe width is set to 1942px, the iframe body is 1942 / 2 = 971px (two pages), with column-width being 971 / 2 = 405.5px. I'm not sure if this matters.
I've attached an html test file to demonstrate.
I used mozregression to narrow this down to 118, and before this release it just previews a blank page (a whole other issue). I've tested this on Fedora 40 and MacOS 14.4.1.
Actual results:
The print window loads, but the preview never renders and is stuck "Preparing Preview". There is no output when saving as PDF, and this ends up crashing the current tab.
Expected results:
Current tab doesn't crash, print preview renders, and I'm able to print what's visible in the viewport.
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 1•2 years ago
|
||
I've also tested & verified this on release 128, and on nightly as of August 6th, 2024.
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Assignee | ||
Comment 3•2 years ago
|
||
I didn't see a crash (though maybe I just didn't wait long enough....), but the issue of being stuck at "Preparing Preview" reproduces for me (on macOS) going back considerably before v.118; mozregression gave me this range, which suggests it regressed in 115:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ffee8e3a7870875ab78af162638548f72cdabddf&tochange=375c5940c253b38f65792c847de04bc50b990b22
| Reporter | ||
Comment 4•2 years ago
|
||
I think this is related: https://bugzilla.mozilla.org/show_bug.cgi?id=1831829
| Assignee | ||
Comment 5•2 years ago
|
||
Yeah, from the range in comment 3, that looks like the most plausible candidate.
I don't think we have the ability to paginate a multicol-inside-an-<iframe> nicely (prior to the regression, the preview shows the entire iframe being scaled to fit within the page), so at least until that is handled, we should exclude this case from being considered as "paginated" here.
| Assignee | ||
Comment 6•2 years ago
|
||
Updated•2 years ago
|
| Assignee | ||
Comment 7•2 years ago
|
||
Without the patch, this fails with a timeout when it attempts to print.
Comment 8•2 years ago
|
||
Set release status flags based on info from the regressing bug 1831829
Updated•2 years ago
|
Comment 11•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4ef68788e380
https://hg.mozilla.org/mozilla-central/rev/42dd1bd7ae7e
Comment 13•2 years ago
|
||
The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox130towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 14•2 years ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D218823
Updated•2 years ago
|
| Assignee | ||
Comment 15•2 years ago
|
||
Without the patch, this fails with a timeout when it attempts to print.
Original Revision: https://phabricator.services.mozilla.com/D218825
Updated•2 years ago
|
Comment 16•2 years ago
|
||
beta Uplift Approval Request
- User impact if declined: Possible infinite-loop (hang)/crash when attempting to preview/print
- Code covered by automated testing: yes
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: n/a
- Risk associated with taking this patch: minimal
- Explanation of risk level: Patch avoids the issue by narrowing the scope of the regressing change to exclude iframe'd subdocuments, so reverting to previous behavior for this case
- String changes made/needed: none
- Is Android affected?: yes
| Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 17•2 years ago
|
||
| uplift | ||
Updated•2 years ago
|
Comment 18•2 years ago
|
||
This grafts cleanly to ESR128. Did you want to nominate for uplift there also?
Comment 19•2 years ago
|
||
| uplift | ||
Updated•2 years ago
|
| Assignee | ||
Comment 20•1 year ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D218823
Updated•1 year ago
|
Comment 21•1 year ago
|
||
esr128 Uplift Approval Request
- User impact if declined: Possible infinite-loop (hang)/crash when attempting to preview/print
- Code covered by automated testing: yes
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: n/a
- Risk associated with taking this patch: minimal
- Explanation of risk level: just avoids trying to handle pagination of iframe'd documents, which led to the problem case
- String changes made/needed: none
- Is Android affected?: yes
Updated•1 year ago
|
Comment 22•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Comment 23•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Description
•