Closed Bug 1659622 Opened 5 years ago Closed 5 years ago

Make clicking the "Print" button in the new print UI a no-op after the first click

Categories

(Toolkit :: Printing, defect, P1)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1659624

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?

Flags: needinfo?(mstriemer)

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".

At the very least, we should probably disable the preview UI while it's printing…
(Except for the non-existant cancel button, of course. ;)

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.

Flags: needinfo?(mstriemer)

Closing the dialog should be done in bug 1659624. This can likely be duped to that provided the print code is okay with it.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.