Able to reproduce the issue on Windows 7,Mac 10.12.6 & Ubuntu 14.04 using chrome stable-60.0.3112.78 & Canary-62.0.3167.0.
Manual Bisect info:
------------------
Good build : 61.0.3136.0-Revision-480665
Bad build : 61.0.3137.0-Revision- 481056

Per revision bisect info:
-------------------------
You are probably looking for a change made after 480861 (known good), but no later than 480862 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+log/b8ae3bdd6f625ef983b2615b74f240506dcbde8b..81e33d3b1082212c0cc3732719167004dcfb63fc

Possible suspect:
-----------------
https://chromium.googlesource.com/chromium/src/+/81e33d3b1082212c0cc3732719167004dcfb63fc

foolip@Could you please take a look and reassign to the right owner if it is not related to your change.
Thanks..!!

I can reproduce this with the extension (maintained by rob@robwu.nl in CC).

However, interestingly, it does not reproduce with https://mozilla.github.io/pdf.js/web/viewer.html open in two tabs.

Another observation is that if one open http://che.org.il/wp-content/uploads/2016/12/pdf-sample.pdf (automatically gets prefixed with chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/) and open the print dialog, then open http://che.org.il/wp-content/uploads/2016/12/pdf-sample.pdf in another tab, that will say "Waiting for extension PDF Viewer..." on a white page, until one goes back to the other page to close the print dialog.

In other words, the print dialog is able to interfere with the other tab in more ways than one.

When it doesn't work, the document.fullscreenElement (#viewerContainer) has a computed style top of 32px. There are two bits of CSS involved here, from chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/content/web/viewer.css:

#viewerContainer.pdfPresentationMode:-webkit-full-screen {
  top: 0px;
  border-top: 2px solid transparent;
  background-color: #000;
  width: 100%;
  height: 100%;
  overflow: hidden;
  cursor: none;
  -webkit-user-select: none;
}

#viewerContainer {
  overflow: auto;
  -webkit-overflow-scrolling: touch;
  position: absolute;
  top: 32px;
  right: 0;
  bottom: 0;
  left: 0;
  outline: none;
}

For some reason, the top block isn't being applied.

It's because the pdfPresentationMode class isn't there. After entering fullscreen, document.getElementById('viewerContainer').className is "". If one doesn't have the print dialog open in the other tab, it's "pdfPresentationMode pdfPresentationModeControls".

Looks like when the print dialog is open, no (webkit)fullscreenchange event is fired, so the code that adds the "pdfPresentationMode" class is never reached.

OK, mystery solved. The event is scheduled (EnqueueEvent) in Fullscreen.cpp, but never fired. This is because it's an animation frame event, handled by ScriptedAnimationController, but ScriptedAnimationController is suspended, in this call chain:

#7 0x7fb2ad222cde blink::ScriptedAnimationController::Suspend()
#8 0x7fb2ad7aaea1 blink::Page::SetPaused()
#9 0x7fb2ad7b690d blink::ScopedPageSuspender::ScopedPageSuspender()
#10 0x7fb2ad797fdd blink::ChromeClient::Print()
#11 0x7fb2ad361b3a blink::LocalDOMWindow::print()

While it is suspended, rAF callback will also not be run, so there are many ways that things could break when the print dialog is open.

I think the fundamental problem is that the the two extension tabs are in the same process, and apparently ScopedPageSuspender suspends all (ordinary) pages in the process.

rdevlin.cronin@, jochen@, I believe you know a think or two about extensions and modal dialogs. Is this (printing suspends other pages in the same process) a symptom of a known bug that it can be duped into?

+also thestig@, who probably knows this best.

AFAIK, printing suspending activity is known (and pseudo-desired?).  We've actually had bugs where the suspension wasn't properly respected by certain subsystems.

This bug makes me think of  issue 702085 , which links to  bug 629431  in comment  https://crbug.com/702085#c7 .

( bug 629431  is not visible to me, so I might be wrong. But if it is relevant, please cc me so that I can know more).

This sounds like the type of problem I want to avoid in bug 139706.

printing suspends the entire renderer, this is WAI, although I argue in issue 629432 that we should fix this

-Internals>Plugins>PDF because this has nothing to do with Chromium's built-in PDF reader.

Closing per #10.