Explore fetching and caching printer information before users initiate printing
Categories
(Toolkit :: Printing, enhancement)
Tracking
()
People
(Reporter: jwatt, Assigned: mstriemer)
References
Details
(Keywords: perf, Whiteboard: [print2020] [old-ui-] )
I don't think there's a good way to fix bug 1663710 without fetching and caching printer information in advance of users initiating printing. It's not clear what we need to do for this to be safe though. Mobile computers moving between networks and driver updates, for example, may mean that cached data can go stale. We need to do this safely.
Comment 1•4 years ago
|
||
For the flip-side of cache invalidation, on the Javascript side, we have some events that trigger "after startup" that might be reasonable times to get (or verify) the data to put into the cache…
Reporter | ||
Comment 2•4 years ago
|
||
Yes, adding something to BrowserGlue._scheduleStartupIdleTasks() looks about right, or if not that then calling ChromeUtils.idleDispatch() directly from somewhere else?
Comment 3•4 years ago
|
||
(Emma worked on that, so would have a more informed opinion which one to use.)
Comment 4•4 years ago
|
||
It worries me to use BrowserGlue._scheduleStartupIdleTasks()
, since the perf team was looking at ways to defer some of those more expensive tasks that we already have implemented. I'd expect this to be considered expensive.
I think in this particular case we should be using _scheduleBestEffortUserIdleTasks()
, which is intended for later startup events that don't have to happen immediately. The risk here is if a user hasn't been idle for a certain amount of time and immediately prints, there's a chance we won't have fetched the printers yet and still see these long wait times. I don't think many users would be trying to print immediately after startup though.
Reporter | ||
Comment 5•4 years ago
|
||
Thanks! Yes, that does sound better. I think the risk you point out is an acceptable trade-off. As long as we can make it extremely rare for users to encounter the very long wait times I think that's acceptable.
Assignee | ||
Comment 6•4 years ago
|
||
Jonathan, do you think we would call the printer API in that background task and that would cache the data or is some other API needed here? I suppose we could also read the values directly from prefs rather than using the current API. Is that what you were thinking?
If the wait times are 10 seconds users could be making changes to the settings and then have the rug pulled out from under a little if that printer is no longer available.
It seems like bug 1661157 has landed and there are recent comments there saying it's fixed the hangs. Maybe we don't need to do this anymore?
Comment 7•4 years ago
|
||
for P1/S1 and only a couple of days before soft-freeze ISTM we should either agree on a plan for this, or re-triage to see if this is in fact still a problem and still potentially blocking. Or is only the exploration a P1, but we anticipate shipping 82 without a solution?
The proposed solution of pre-fetching printer info with _scheduleBestEffortUserIdleTasks() might work in most cases, but we need to know how & when to invalidate that cache. If we present stale information in the print dialog, that is arguably worse than blocking the user while we wait for the printer info in real-time, as an attempt to print could fail. Do we have a way to be notified when the user joins or leave a network? That would only leave the case where the user plugs in or powers on an attached or network printer.
I'm not totally clear on what causes the long delay, and what we are doing now that we didn't do before?
I think we are better placed now to update printer info while the user is interacting with the UI - as bug 1663669 should enable us to restore most settings even if the available printers change. But we should still have some UI affordance - something like a banner that says "Available printer information has changed, click to refresh"
Reporter | ||
Comment 8•4 years ago
|
||
This would be too risky for v82. Bug 1666938 is a more likely v82 candidate if we're going to try anything at this point.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Moving things to 88, cause we're mostly on Proton these days…
Reporter | ||
Updated•4 years ago
|
Comment 10•3 years ago
|
||
decreasing severity as this as an enhancement and has been open for a while.
Description
•