Open Bug 1686983 Opened 3 years ago Updated 19 days ago

The print preview takes minutes to display for pages that contain images that failed to load

Categories

(Core :: Print Preview, defect)

Product:
Core
Component:
Print Preview
Type:
defect

Tracking

()

Project Flags:
Performance Impact medium

People

(Reporter: florian, Assigned: jwatt)

References

(
URL
)

Details

(Keywords: perf, perf:pageload, reproducible, Whiteboard: [print2020_v90])

I encountered a page where the print preview took more than a minute to display. Some debugging showed that when showing the print preview, we were attempting to load an image from the network, and then waiting until a timeout.

Here's a reduced test case:

  1. Load this url in a tab:
    data:text/html,test<img%20src="http://img11.hostingpics.net/pics/name.jpg"%20alt="%20timeout"%20border="0"%20/>

  2. Observe that the loading indicator in the tab remains for a very long time. While the loading indicator is still active, the tab content shows "test". If you wait long enough, the loading indicator stops, and the tab content becomes "test timeout".

  3. Press cmd+P to open the print dialog that should show the print preview.
    Expected result: a preview similar to what's shown in the tab should appear.
    Actual result: the "Preparing Preview" message remains for a very long time (more than a minute).

Using the profiler, I notice that opening the print dialog causes another network request for the broken image, and that we wait until the network timeout before moving on. Here's a profile for the reduced test case: https://share.firefox.dev/3nLiPG3

I tried on Safari, and the print preview there shows what's displayed in the tab, immediately.

Note: img11.hostingpics.net is a server that currently doesn't respond. If I try to load the image directly in a tab, I get this error message:
"The connection has timed out

The server at img11.hostingpics.net is taking too long to respond.
The site could be temporarily unavailable or too busy. Try again in a few moments."

Whiteboard: [print2020_v86]

I wonder what the result is on real printing output on Safari. Safari doesn't wait for the image's timeout? Also wondering once after Safari implemented lazy loading for images, how they handle it.

Anyway, setting S3 since I think it rarely happens.

Severity: -- → S3
See Also: → 1687576

I think I could replicate this issue by narrowing down the network bandwidth on devtool. And it seems Chrome doesn't wait for image load completions at all on print preview. Once after some print settings were changed, it updates preview window, then unloaded images will appear there.

As the person who opened the duplicate bug 1693407, I just wanted to add that the 60-second-stall behavior happens even if I'm in safe mode.

Bumping up severity to S2 since I believe this is a major source of issues that print preview window takes long time to be opened. We should do something to mitigate this. :jwatt?

Severity: S3 → S2
Flags: needinfo?(jwatt)
See Also: → 1679506
Whiteboard: [print2020_v86] → [print2020_v87]
Flags: needinfo?(jwatt)
Keywords: perf
Assignee: nobody → jwatt
URL: data:text/html,<img src="https://soft...

Print style sheets may reference external images that are not referenced by the screen style sheet. We have the nsPrintJob::MaybeResumePrintAfterResourcesLoaded and nsPrintJob::ShouldResumePrint code to wait for those resources to load before declaring the print preview document complete. The frontend code waits for the print preview to be complete before displaying it. This doesn't behave well when one or more of the resources may take some time to load.

Chrome and Safari have different behavior to Firefox and slightly different behavior to each other.

Neither Chrome nor Safari wait for the print style sheet's external resources to load, and the resources loading while the print preview is still being displayed does not cause the preview to be updated to include those resources. However, the print preview will update to include them if you force it to reflow/repaginate by changing paper size, or even just toggle headers and footers on/off.

Where Chrome and Safari differ slightly is in actual print output. If an external resource loads while the preview is displayed - and assuming a user action doesn't force a reflow - Chrome will output exactly what's in the preview in the final print output, whereas Safari will reflow/repaginate the final print output to include the newly loaded resources.

A testing data URI (in the print/print preview there should be a green square between "foo" and "bar"):

data:text/html,<style media="print">span::after { content: url("https%3A%2F%2Fsoftware.hixie.ch%2Futilities%2Fcgi%2Ftest-tools%2Fdelayed-file%3Fmime%3Dimage%252Fgif%26text%3DGIF87a%20%2500%20%2500%2580%2501%2500%2500%25FF%2500%25FF%25FF%25FF%252C%2500%2500%2500%2500%20%2500%20%2500%2500%2502%251E%2584%258F%25A9%25CB%25ED%250F%25A3%259C%25B4%25DA%258B%25B3%25DE%25BC%25FB%250F%2586%25E2H%2596%25E6%2589%25A6%25EA%25CA%25B6%25EE%250B%259B%2505%2500%253B%26pause%3D5"); }</style><span>foo</span>bar

(The "5" in the "3D5" in the URI is the number of seconds delay. Note that once loaded the image is in cache and its load isn't delayed again.)

Our behavior was originally introduced in bug 468568 (84317c2f19), although it was introduced to wait for fonts to download, rather than images. (ResumePrintAfterResourcesLoaded was called AfterNetworkPrint back then.)

The behavior of our old Print Preview UI is to load the print preview document immediately. If external resources subsequently load then the print preview document automatically reflows.

If I change nsPrintJob::ShouldResumePrint to return !mDoingInitialReflow then our new Print Preview UI appears to behave like Safari (the preview doesn't update unless a settings change forces a reflow, but the final print output will be updated regardless).

Currently I think our old print preview behavior is the best on balance. Having the final output be different to the preview seems worst (delayed font or image loads could potentially significantly change the number of pages - does that mean pages will be missing, or more pages than expected will print?) Not automatically including print style sheet external resources unless a manual print settings change is made doesn't seem great.

Whiteboard: [print2020_v87] → [print2020_v90]
Performance Impact: --- → ?

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: macOS
Configuration: Rare
Page load impact: Severe
Websites affected: Rare
[x] Able to reproduce locally
[x] Bug affects multiple sites
[x] Multiple reporters

Performance Impact: ? → high
Keywords: perf:pageload, reproducible
Performance Impact: high → medium

Dropping severity to S3 to reflect reality, per reduced performance-impact (comment 12) and since the STR with comment 9's data-URI (with a multi-second download time for an image that's only rendered in the print-specific stylesheet) don't seem super representative.

Also: the independent reports here (comment 4, comment 6 - comment 7) were almost certainly about one or two different bugs that have been long fixed at this point. (bug 1693407 from comment 4 was updated to WORKSFORME when the reporter could no longer repro their reported 60-second hang anymore; and the comment 6 description of e.g. "change the printer ... wait another 30 seconds" does not match our current behavior with our data-URL testcase here; nowadays, there should only be a wait while the image is downloading, and subsequently it'll be cached & won't trigger further delay if you e.g. adjust settings or change printer or click through to print.)

Would still be great to fix this when someone has cycles to do so. jwatt's analysis in comment 10 - comment 11 will be useful when someone picks this up.

Severity: S2 → S3

Also: for reference, here's a longer "explicit 60-second-wait" version of jwatt's data-URI testcase:

data:text/html,<style media="print">span::after { content: url("https%3A%2F%2Fsoftware.hixie.ch%2Futilities%2Fcgi%2Ftest-tools%2Fdelayed-file%3Fmime%3Dimage%252Fgif%26text%3DGIF87a%20%2500%20%2500%2580%2501%2500%2500%25FF%2500%25FF%25FF%25FF%252C%2500%2500%2500%2500%20%2500%20%2500%2500%2502%251E%2584%258F%25A9%25CB%25ED%250F%25A3%259C%25B4%25DA%258B%25B3%25DE%25BC%25FB%250F%2586%25E2H%2596%25E6%2589%25A6%25EA%25CA%25B6%25EE%250B%259B%2505%2500%253B%26pause%3D60"); }</style><span>foo</span>bar

(with %3D60 at the end of the data-URI indicating a 60-second wait. I didn't use a larger value since larger values seem to nerf the whole delay, based on my testing, maybe due to Hixie's utility-script not wanting to be hung up for too long.)

When I print-preview this^, I see a throbber for 60 seconds while we wait for the image to load (not great, but that's just how long the image data takes to arrive in this case). And then from that point, I confirmed that I get no delays when changing settings, leaving/reentering print-preview, etc.

(In reply to Daniel Holbert [:dholbert] from comment #14)

I see a throbber for 60 seconds while we wait for the image to load (not great, but that's just how long the image data takes to arrive in this case). And then from that point, I confirmed that I get no delays when changing settings, leaving/reentering print-preview, etc.

The bug was initially reported with an image that never loads because the server doesn't respond. Would that be cached too? Or is the "no delays when changing settings, leaving/reentering print-preview" part of your comment a side effect of using an image that eventually loads?

While not exactly common, the website where I initially encountered the bug was a forum page where I was reading posts from multiple years ago, and some of the people had a link in their signature that pointed to an image hosting provider that no longer existed, or was down at the moment. I think that's a case some users are likely to encounter.

(In reply to Dave Hunt [:davehunt] [he/him] ⌚GMT from comment #12)

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: macOS
Configuration: Rare

Is there something that indicates the bug would only happen on Mac? I think this happens in a cross platform part of our printing code.

Flags: needinfo?(dholbert)
Flags: needinfo?(dave.hunt)

(In reply to Florian Quèze [:florian] from comment #15)

The bug was initially reported with an image that never loads because the server doesn't respond. Would that be cached too? Or is the "no delays when changing settings, leaving/reentering print-preview" part of your comment a side effect of using an image that eventually loads?

I don't know for sure, to be honest. The STR in comment 0 are fine (no bug) right now, presumably because http://img11.hostingpics.net/ is more thoroughly down than it was at the point that this bug was filed.

It would be nice to have a reproducible testcase (or STR) to demonstrate the network-timeout scenario, if it's possible for someone to come up with steps or a testcase there. At the moment I'm not sure how to test that. (I could imagine spinning up my own bespoke http server to send back just enough to keep the connection alive but not enough to have it complete, but that's more of a rabbit-hole than I can go down at the moment).

While not exactly common, the website where I initially encountered the bug was a forum page where I was reading posts from multiple years ago, and some of the people had a link in their signature that pointed to an image hosting provider that no longer existed, or was down at the moment. I think that's a case some users are likely to encounter.

I'm not an expert on networking errors, but I think it'd be uncommon for this sort of forum situation (with <img src="long-gone.example.com/foo.jpg">) to lead to network timeouts of the sort you described in comment 0. Those should produce pretty-instant 404 or server-not-found errors, rather than hanging for seconds or minutes waiting for a response. I suspect the thing you described in comment 0 requires some special flavor of badness, like a misconfigured server/router/DNS resolver.

In particular: your data-URI example in comment 0 loads just fine for me right now (with no image, and no hang), since the image request gets back a "Server not found" error quite quickly.

Is there something that indicates the bug would only happen on Mac? I think this happens in a cross platform part of our printing code.

(Yeah, I don't think this was mac-specific. Comment 6 mentioned macOS, and comment 4's originally-duped-bug 1693407 was on macOS, but as I noted I think those were both distinct issues. I wouldn't assume that this is platform-specific.)

Flags: needinfo?(dholbert)

I ran this through the calculator again indicating that it's cross-platform (at least desktop platforms). The impact was the same.

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: [x] Windows [x] macOS [x] Linux
Configuration: Rare
Page load impact: Severe
Websites affected: Rare
[x] Able to reproduce locally
[x] Bug affects multiple sites
[x] Multiple reporters

Flags: needinfo?(dave.hunt)

(In reply to Dave Hunt [:davehunt] [he/him] ⌚GMT (PTO until Jan-3) from comment #17)

Configuration: Rare

Assuming this is about the user's machine, there's nothing rare about it. Any user trying to print a webpage containing a non-loading image would encounter this.

(In reply to Florian Quèze [:florian] from comment #18)

(In reply to Dave Hunt [:davehunt] [he/him] ⌚GMT (PTO until Jan-3) from comment #17)

Configuration: Rare

Assuming this is about the user's machine, there's nothing rare about it. Any user trying to print a webpage containing a non-loading image would encounter this.

In that case, it's high impact according to the calculator.

The Performance Impact Calculator has determined this bug's performance impact to be high. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: [x] Windows [x] macOS [x] Linux
Page load impact: Severe
Websites affected: Rare
[x] Able to reproduce locally
[x] Bug affects multiple sites
[x] Multiple reporters

Performance Impact: medium → high

The severity field for this bug is set to S3. However, the Performance Impact field flags this bug as having a high impact on the performance.
:jwatt, could you consider increasing the severity of this performance-impacting bug? Alternatively, if you think the performance impact is lower than previously assessed, could you request a re-triage from the performance team by setting the Performance Impact flag to ??

For more information, please visit auto_nag documentation.

Flags: needinfo?(jwatt)
Duplicate of this bug: 1687576

:jwatt can you review this bug and determine if the severity matches the performance impact? A High impact would translate to a S2. If you feel this is an S3, can you comment on the mismatch between our calculations and yours and we can reassess the impact?

(In reply to Frank Doty [:fdoty] from comment #22)

:jwatt can you review this bug and determine if the severity matches the performance impact? A High impact would translate to a S2. If you feel this is an S3, can you comment on the mismatch between our calculations and yours and we can reassess the impact?

I'd quibble with a part of the performance triage calculator assessment:

Page load impact: Severe

The core issue here has zero impact on page load. It's specific to the print dialog coming up (and the print dialog waiting for an image to load that never loads, and eventually timing out).

(Comment 0 does mention "Observe that the loading indicator in the tab remains for a very long time" -- that's not a Firefox bug or a Firefox-specific issue, though. That's just the circumstances that are required to trigger the bug, with an image on a slightly-responsive-but-mostly-unresponsive-server.)

And clarifying part of this point:
(In reply to Florian Quèze [:florian] from comment #18)

Any user trying to print a webpage containing a non-loading image would encounter this.

This is more specific than "non-loading image" - to reproduce this, I think the server hosting the image has to accept the connection but refuse to return all of the image's data, or something along those lines, in order to produce the sort of network timeout that's involved here. Most mundane "image fails to load" sort of situation (due to e.g. hosts being completely offline, bad URLs, or data corruption) would not trigger this issue.

Anyway, putting my triage sheriff hat on, here's my triage assessment using the perf triage calculator (note, I'm calling the print dialog spinning "Impact on site: Causes noticeable jank" , since that seems closest; it doesn't impact the rest of the browser, you can still switch tabs or close tabs, so "Impact on browser" is accurately "Minor")

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: [x] Windows [x] macOS [x] Linux [x] Android
Impact on site: Causes noticeable jank
Websites affected: Rare
[x] Able to reproduce locally
[x] Bug affects multiple sites
[x] Multiple reporters

Performance Impact: high → medium
Flags: needinfo?(jwatt)
You need to log in before you can comment on or make changes to this bug.