Using the per-revision bisect providing the bisect results,
Good build:58.0.3025.0 (Revision:453134).
Bad build:58.0.3026.0 (Revision:453454).

You are probably looking for a change made after 453317 (known good), but no later than 453318 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/09ac3a21d0b908ca26d0898f58ea77be7e9462d2..9e1897b5c7dab9c190fc3c919a1c4662af63b3e6

From the CL above, assigning the issue to the concern owner

@nasko : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url:  https://codereview.chromium.org/2715363002
Note :Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Mac 10.12.3 and Able to reproduce in latest Canary #59.0.3043.0
Adding Release Block-Stable for this issue.Please remove if not the case.

Yes, this looks like regression due to enabling "Isolate Extensions" feature. 

Running with a local build from about a week or so ago, I get this:

[61301:61301:0316/111259.025206:FATAL:print_view_manager.cc(138)] Check failed: NOT_PREVIEWING != print_preview_state_ (0 vs. 0)
#0 0x7f77d116fe81 __interceptor_backtrace
#1 0x7f77cf203e2c base::debug::StackTrace::StackTrace()
#2 0x7f77cf285077 logging::LogMessage::~LogMessage()
#3 0x7f77d2fe2d67 printing::PrintViewManager::PrintPreviewDone()
#4 0x7f77d2fdf7bb printing::PrintPreviewDialogController::RemoveInitiator()
#5 0x7f77d2fdd2a9 printing::PrintPreviewDialogController::OnNavEntryCommitted()
#6 0x7f77d2fdbee9 printing::PrintPreviewDialogController::Observe()
#7 0x7f77c65e1cf9 content::NotificationServiceImpl::Notify()
#8 0x7f77c60faa51 content::NavigationControllerImpl::RendererDidNavigate()
#9 0x7f77c614b683 content::NavigatorImpl::DidNavigate()
#10 0x7f77c6169702 content::RenderFrameHostImpl::OnDidCommitProvisionalLoad()
#11 0x7f77c6161067 content::RenderFrameHostImpl::OnMessageReceived()
#12 0x7f77c685334a content::RenderProcessHostImpl::OnMessageReceived()
#13 0x7f77ccaf0d49 IPC::ChannelProxy::Context::OnDispatchMessage()
#14 0x7f77ccafa26f _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#15 0x7f77cf206659 base::debug::TaskAnnotator::RunTask()
#16 0x7f77cf2b44ab base::MessageLoop::RunTask()
#17 0x7f77cf2b5466 base::MessageLoop::DeferOrRunPendingTask()
#18 0x7f77cf2b6acb base::MessageLoop::DoWork()
#19 0x7f77cf2c16a7 base::(anonymous namespace)::WorkSourceDispatch()
#20 0x7f77b4e40e04 g_main_context_dispatch
#21 0x7f77b4e41048 <unknown>
#22 0x7f77b4e410ec g_main_context_iteration
#23 0x7f77cf2c0986 base::MessagePumpGlib::Run()
#24 0x7f77cf2b3ab1 base::MessageLoop::RunHandler()
#25 0x7f77cf367d51 base::RunLoop::Run()
#26 0x7f77d2d46b2c ChromeBrowserMainParts::MainMessageLoopRun()
#27 0x7f77c5d2d99e content::BrowserMainLoop::RunMainMessageLoopParts()
#28 0x7f77c5d3a536 content::BrowserMainRunnerImpl::Run()
#29 0x7f77c5d1ef9c content::BrowserMain()
#30 0x7f77c7bc8d77 content::RunNamedProcessTypeMain()
#31 0x7f77c7bcab5b content::ContentMainRunnerImpl::Run()
#32 0x7f77c7bc5d9b content::ContentMain()
#33 0x7f77d11f9510 ChromeMain
#34 0x7f77afae4f45 __libc_start_main
#35 0x7f77d1120c19 <unknown>

thestig@, would you be able to look at this one?

Oh, https://codereview.chromium.org/2742853003/ might be the fix for this and I don't have it in my build.

This might be really bad.  It looks like *no* future navigations can happen in any tab after this, until you kill the PDF Viewer extension process.  I'm guessing that process is blocked on a modal dialog and didn't get unblocked when going back, and that seems to prevent future navigations.

It affects M57 as well.

Ok, I confirmed locally that the fix from https://codereview.chromium.org/2742853003/ is indeed fixing the issue. 

I also have a hypothesis why this happens. Before the fix, when the autodismissal of the print preview was happening, the cleanup wasn't properly performed, so the sync IPC from the renderer process to the browser process was left hanging. Because with "Isolate Extensions" the printing subframe runs in the extension process, this means that the hung process is the extension one.
That specific extension also uses the webRequest API in blocking mode, which means that network requests need to be sent to the extension to evaluate and allow or block. Since the extension process is still waiting on the sync IPC from printing, there is no progress being made. Therefore network activity is blocked waiting for the extension process. alexmos@ confirmed that if the extension process is killed, the browser recovers (prior to the fix).

+rdevlin.cronin... I wonder if this regressed when we started making extension script execution obey page suspension in  issue 629431 

thestig: Are you planning on merging r457363 to M58 and M57?  (I would assume so given  issue 698622 .)

Another observation is that you can't navigate in any other tab while the PDF Viewer has a print dialog open.

This wasn't a problem before --isolate-extensions because the print was done from the tab's process, and the extension process wouldn't be blocked.  Now that the extension iframe lives in the extensions process (with the launch of --isolate-extensions), any modal dialog ends up blocking all web requests, which is really unfortunate.

I wonder if there's a way to avoid doing modal dialogs like printing from the extension process itself?  Or on Chrome's side, if we can avoid having sync IPCs block web requests, as dcheng mentioned?

@7 It's entirely possible that this is because of transitioning to obey page suspension.  If the print preview dialog blocks script injection and doesn't let the webRequest event handler run, we can't proceed with any navigation because we let the extension dictate what we do.

IMO, anything that requires page suspension (print preview, modal dialogs) shouldn't be allowed in a webRequestBlocking extension process. Sync XHRs seem like something else that may be problematic.

Let's verify that this is the cause first though.

creis: Yes, I will merge r457363 to M58 and then M57.

dcheng: I can confirm that changing SuspendableScriptExecutor::run() to always call executeAndDestroySelf() (by changing the conditional from !context->isContextSuspended() to true) does affect this.  I'm able to navigate other tabs while the extension's print preview tab is showing.

Sounds like  issue 629431  is indeed involved.

Filed issue 702359 to track the issue for webRequestBlocking.

This is a regression in M58 and tagged as RBS. Please try to resolve ASAP.

Comment 14: I can confirm that this particular bug is fixed in 59.0.3044.0, by r457363.  That will get merged to M58 (and M57) as part of issue 702359.

We'll follow up with the fact that network requests won't work while the print dialog is open in issue 702359.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-58; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-58 label, otherwise remove Merge-TBD label. Thanks.

Merged in https://chromium.googlesource.com/chromium/src/+/23107311dcb2bc1ecfa1c0fbe63f5f210c154049