Untriaging it so that it gets addressed.

Able to reproduce. Tried reducing the steps, but these already seem to be minimal.

Assigning to thestig@, please confirm if this is in the correct component.

I tried with 62.0.3202.9 on Linux and I can't reproduce. This is a different PDF viewer, so we should change the component, but I don't know what the right component is yet.

I can reproduce with 63.0.3213.3. Maybe this is a regression?

I can reproduce with 62.0.3202.x. It's just a bit flaky sometimes.

eae: That's not the Chrome PDF Viewer. :-P

avshaikh@ thanks for the issue.

Able to reproduce this issue on Windows 7, Mac OS 10.12.6 and Ubuntu 14.04 using the latest Canary 63.0.3218.0 and latest Dev 63.0.3213.3.

This issue is seen from 62.0.3189.0 since the 'Presentation mode' option was introduced. The previous builds had no Presentation mode option under Tools menu. Triaging this as Non-regression issue and removing the Needs- bisect label.

Thanks

This is independent of extensions. The web page directly uses PDF.js.

Some observations:
- document.webkitFullscreenEnabled returns true in the latest canary (and apparently also 62). This is not the case in 61, and I cannot readily find documentation or bugs that assert that this is expected behavior.

- Because of the lack of a proper printing API, PDF.js needs to render the pages before printing it, so contextmenu->print is not going to do anything useful. To print, press Ctrl-P within the page (which is intercepted by PDF.js, which renders the page and invokes window.print()).

- When window.print() is called, the browser exits full screen mode. When the context menu's print is used, the page stays in full screen mode.

- When I scroll up after the black window is shown, PDF.js renders the page again.

In short, the black page is not a bug with Chrome, but an expected (but undesirable) consequence of PDF.js's printing logic.
However, the changed behavior w.r.t document.webkitFullscreenEnabled needs more investigation (if the behavior is unintentional, it better be fixed before 62 hits stable). Also the difference in fullscreen-exiting behavior of window.print() versus browser-initialized print might be worth a look too.

Over to foolip to comment on the change between 61 and 62 mentioned above,

#11, on document.webkitFullscreenEnabled, are you saying that it is always true? Can you share a test case that I could use to bisect? Something that does console.log at the appropriate time would be fine.

#13 Just open the following test file.
It hosts a frame that prints document.webkitFullscreenEnabled from the frame.

Good = "document.webkitFullscreenEnabled = false"
Bad  = "document.webkitFullscreenEnabled = true"

Deleted: crbug765142.html 292 bytes

crbug765142.html 292 bytes View Download

This sounds fairly similar to  issue 749466 , but might not be the same after all. Taking another look.

I bisected using crbug765142.html and got this range:
https://chromium.googlesource.com/chromium/src/+log/81565fa69c0d5cdd4275fcf9d858f92b5e8aa551..4f0ac7d5ecff04ffec2466b50869b58b53e9f632

https://chromium.googlesource.com/chromium/src/+/5d8010e1fc081481d0646618e700b51a4699ab4c is the culprit, which was in 62.0.3189.0. I know that this was an intentional change, but assigning to iclelland@ to advise about how to adapt to the change.

This was intentional -- webkitFullscreenEnabled should be true (or false) for the entire document lifetime; it is no longer settable dynamically by the containing document. Also, it is true by default for same-origin frames, to better reflect the reality that a same-origin embedded document has full access to its parent's state.

Entering and exiting fullscreen mode shouldn't be affected by that change; I'm not sure where the black page is coming from in those cases (unless it's a consequence of PDF.js using the value of webkitFullScreenEnabled in an unexpected way, or trying to use onfullscreenerror for control flow or something like that).