Session restore should not restore print preview doorhangers
Categories
(Toolkit :: Printing, defect, P2)
Tracking
()
People
(Reporter: jwatt, Unassigned)
References
Details
(Whiteboard: [print2020_v83])
Filing another bug I didn't get around to filing at the time.
I noticed that after crashing, session restore will restore the doorhanger containing a print preview. Or at least, it will try. The preview will be non-functional and, if I recall correctly, the only way to get rid of it is to refresh the page or navigate.
Print preview doorhangers should not be stored in session history.
|
||
Comment 1•5 years ago
|
||
Can you elaborate on steps to reproduce? Normal session restore doesn't appear to do this, and there's just 2 mentions of print / preview in session restore code, at https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/browser/components/sessionstore/SessionStore.jsm#5562 and a little further down - neither seems like it'd have this effect.
In general, I don't think we store/restore dialog state, print preview or otherwise...
|
||
Comment 2•5 years ago
|
||
[Moving front-end printing v82 bugs to v83.]
|
|
||
Comment 3•5 years ago
|
||
Is it possible the print dialog was a result of the page calling window.print ? I could see that coming up again with session restore, and depending on caching or racing at startup, perhaps there's a weird issue there?
|
||
Comment 4•5 years ago
|
||
Comment 3 seems much more likely the cause here. I'm going to close out this bug as incomplete since it's been over 14 days without a response. @jwatt, please reopen the bug if you have steps to reproduce.
|
Reporter | |
Comment 5•5 years ago
|
||
Just to close the loop here, I can't reproduce this any more. I can't remember exactly what page it happened on but from what I recall I was using one of my test pages, and window.print was not involved.
Description
•