Make clicking the "Print" button in the new print UI a no-op after the first click
Categories
(Toolkit :: Printing, defect, P1)
Tracking
()
People
(Reporter: jwatt, Unassigned)
References
Details
(Whiteboard: [print2020_v81])
It looks like the new print UI sending a second call to initiate a print to the platform code in quick succession is the cause of the crash in bug 1658196.
The platform code could be changed to return an error in this case, but then there's the issue of the frontend error handling code kicking in and closing the doorhanger while the print initiated by the original click on "Print" is proceeding just fine. Safer would be to make sure that first the frontend isn't triggering such an error condition so that we can safely make that change in the platform code.
Can we make clicking on the "Print" button a no-op after it's been clicked on once?
|
Reporter | |
Comment 1•5 years ago
|
||
I suppose this, as reported, only makes sense if we implement bug 1659624. Until that happens the request should probably be modified to "disable it until the current print has finished".
|
||
Comment 2•5 years ago
|
||
At the very least, we should probably disable the preview UI while it's printing…
(Except for the non-existant cancel button, of course. ;)
|
||
Comment 3•5 years ago
|
||
We should be able to window.close() here once the print has been started. Provided we are okay with dropping the reference to the print preview browser.
|
|
||
Comment 4•5 years ago
|
||
Closing the dialog should be done in bug 1659624. This can likely be duped to that provided the print code is okay with it.
Description
•