Sure! I'm not quite sure if this is the correct way to test what we need, but I loaded a `.pdf` and tried to call `window.print()` from `about:debugging` in the content process. Unfortunately, the `.pdf` did not print this way. This [seems like the related log warning](https://searchfox.org/mozilla-central/rev/8ed22fcd56968c95a73a6c82b42f732f01a4bdae/dom/canvas/WebGLContext.cpp#1774) that showed up. If testing calling `window.print` from a `pdf.js` page this way was valid, I think the issue might be that it tries to capture a browser clone first and then makes the call that would check for PDF.js, which then gets the PDF sent on to the printer. It should maybe check for PDF.js first and not make a clone in that situation before requesting the PDF because the clone will not be needed. (`geckoview.js` -> `onPrintWindow` code). (I'll test this idea later today.) Alternatively, we don't have printing as a menu option on Fenix/Focus yet (bug 1808755), but we do in GeckoView Example. Printing a `.pdf` page worked as expected when I tested printing from the menu on GVE. This calls [printPageContent](https://searchfox.org/mozilla-central/rev/8ed22fcd56968c95a73a6c82b42f732f01a4bdae/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java#6807) directly without needing to make a browser clone first.
Bug 1810111 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Sure! I'm not quite sure if this is the correct way to test what we need, but I loaded a `.pdf` and tried to call `window.print()` from `about:debugging` in the content process. Unfortunately, the `.pdf` did not print this way. This [seems like the related log warning](https://searchfox.org/mozilla-central/rev/8ed22fcd56968c95a73a6c82b42f732f01a4bdae/dom/canvas/WebGLContext.cpp#1774) that showed up. If testing calling `window.print` from a `pdf.js` page this way was valid, I think the issue might be that it tries to capture a browser clone first and then makes the call that would check for PDF.js, which then gets the PDF sent on to the printer. It should maybe check for PDF.js first and not make a clone in that situation before requesting the PDF because the clone will not be needed. (`geckoview.js` -> `onPrintWindow` code). (I'll test this idea later today. ) **Update:** Tried the idea in the above paragraph. I adjusted the code to send directly to the PDF and printing stage without a browser clone attached. This test change did not seem to solve the issue. The same warning still appeared. Gecko did need a browsing context, so I did return one in the test. Alternatively, we don't have printing as a menu option on Fenix/Focus yet (bug 1808755), but we do in GeckoView Example. Printing a `.pdf` page worked as expected when I tested printing from the menu on GVE. This calls [printPageContent](https://searchfox.org/mozilla-central/rev/8ed22fcd56968c95a73a6c82b42f732f01a4bdae/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java#6807) directly without needing to make a browser clone first.