Bugzilla

(In reply to Jonathan Kew [:jfkthame] from comment #20)
> The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does `window.print(); window.close()` [...] if such a window has pdf.js content, or for some other reason uses mozPrintCallback, 

So, two pieces of good news:
(1) We never got this case actually-working; bug 1959052 made this hypothetical-scenario go from "popup window mysteriously closes" to "popup window mysteriously prints blank pages instead of the actual PDF".  So the patch that I landed here didn't really regress that case; it was never really working in the first place.

(2) That case (PDF in popup with window.print();window.close()) is actually broken in Chrome as well, and in Firefox with the regular print dialog. I've got some testcases in bug 1985400 to demonstrate.

So: this is all good news because it means that the potential regression "cost" of taking this patch (that jfkthame describes in comment 20) is not actually a regression [that situation was & continues to be broken] and it's also not likely to be something that web content is likely to do, possibly because you can't robustly run your own random scripts in window.print()-spawned PDF because you have no idea what sort of environment will be displaying it.

(In reply to Jonathan Kew [:jfkthame] from comment #20)
> The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does `window.print(); window.close()` [...] if such a window has pdf.js content, or for some other reason uses mozPrintCallback, 

So, two pieces of good news:
(1) We never got this case actually-working; bug 1959052 made this hypothetical-scenario go from "popup window mysteriously closes" to "popup window mysteriously prints blank pages instead of the actual PDF".  So the patch that I landed here didn't really regress that case; it was never really working in the first place.

(2) That case (PDF in popup with window.print();window.close()) is actually broken in Chrome as well, and in Firefox with the regular print dialog. I've got some testcases in bug 1985400 to demonstrate.

So: this is all good news because it means that the potential regression "cost" of taking this patch (that jfkthame describes in comment 20) is not actually a regression [that situation was & continues to be broken] and it's also not likely to be something that web content is likely to do since it's similarly broken in Chrome.  Possibly nobody bothers to rely on doing that sort of thing, because you can't robustly run your own random scripts in window.print()-spawned PDF because you have no idea what sort of environment will be displaying it.

(In reply to Jonathan Kew [:jfkthame] from comment #20)
> The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does `window.print(); window.close()` [...] if such a window has pdf.js content, or for some other reason uses mozPrintCallback, 

So, two pieces of good news:
(1) We never got this case actually-working; bug 1959052 made this hypothetical-scenario go from "popup window mysteriously closes" to "popup window mysteriously prints blank pages instead of the actual PDF".  So the patch that I landed here didn't really regress that case; it was never really working in the first place.

(2) That case (PDF in popup with window.print();window.close()) is actually broken in Chrome as well, and in Firefox with the regular print dialog. I've got some testcases in bug 1985400 to demonstrate.

So: this is all good news because it means that the potential regression "cost" of taking this patch (that jfkthame describes in comment 20) is not actually a regression [that situation was & continues to be broken] and it's also not likely to be something that web content is likely to do since it's similarly broken in Chrome.  Possibly nobody bothers to rely on doing that sort of thing, because you can't robustly run your own random scripts in window.open()-spawned PDF document, because you have no idea what sort of environment will be displaying it (whether PDF.js or PDFium or an embedded plugin or something else)

(In reply to Jonathan Kew [:jfkthame] from comment #20)
> The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does `window.print(); window.close()` [...] if such a window has pdf.js content, or for some other reason uses mozPrintCallback, 

So, two pieces of good news:
(1) We never got this case actually-working; bug 1959052 made this hypothetical-scenario go from "popup window mysteriously closes" to "popup window mysteriously prints blank pages instead of the actual PDF".  So the patch that I landed here didn't really regress that case; it was never really working in the first place.

(2) That case (PDF opened in popup-window, with window.print();window.close()) is actually broken in Chrome as well, and in Firefox with the regular print dialog. I've got some testcases in bug 1985400 to demonstrate.

So: this is all good news because it means that the potential regression "cost" of taking this patch (that jfkthame describes in comment 20) is not actually a regression [that situation was & continues to be broken] and it's also not likely to be something that web content is likely to do since it's similarly broken in Chrome.  Possibly nobody bothers to rely on doing that sort of thing, because you can't robustly run your own random scripts in window.open()-spawned PDF document, because you have no idea what sort of environment will be displaying it (whether PDF.js or PDFium or an embedded plugin or something else)

(In reply to Jonathan Kew [:jfkthame] from comment #20)
> The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does `window.print(); window.close()` [...] if such a window has pdf.js content, or for some other reason uses mozPrintCallback, 

So, two pieces of good news:
(1) We never got this case actually-working (with PDF/mozPrintCallback content at least); bug 1959052 made this hypothetical-scenario go from "popup window mysteriously closes" to "popup window mysteriously prints blank pages instead of the actual PDF".  So the patch that I landed here didn't really regress that case; it was never really working in the first place.

(2) That case (PDF opened in popup-window, with window.print();window.close()) is actually broken in Chrome as well, and in Firefox with the regular print dialog. I've got some testcases in bug 1985400 to demonstrate.

So: this is all good news because it means that the potential regression "cost" of taking this patch (that jfkthame describes in comment 20) is not actually a regression [that situation was & continues to be broken] and it's also not likely to be something that web content is likely to do since it's similarly broken in Chrome.  Possibly nobody bothers to rely on doing that sort of thing, because you can't robustly run your own random scripts in window.open()-spawned PDF document, because you have no idea what sort of environment will be displaying it (whether PDF.js or PDFium or an embedded plugin or something else)