Unable to reproduce this issue. Could you be more precise about what you mean by "nothing happens"? Does the link not take you anywhere, or do you just see a grey screen where the PDF should be loaded?

The link doesn't go anywhere. ... Likely a navigation problem not a PDF problem I guess?

Oh, I just updated to 59.0.3067.1 and it seems fine again. So I guess this is probably a dupe, but I won't worry about it.

Thanks for checking!

I have the same issue in 59.0.3067.0, with no update being made available.

Do we know what's changed between .0 and .1? I have no update available for .1

Maybe this is PlzNavigate related?

Marking back to Untriaged. Good gut, thestig@

My full Finch flags (translated) are:
AutoDismissingDialogs-Enabled
AutofillFieldMetadata-Enabled
BackgroundVideoOptimizations-Disabled
BrowserScheduler-Control9
BrowserSideNavigation-Enabled_50
CSSExternalScanner-Enabled_ScanOnly
CaptivePortalCertificateList-Enabled
ChromeChannelCanary-Enabled
ClientSideDetectionModel-Model3
DataReductionProxyUseQuic-Enabled11
DefaultEnableGpuRasterization-DefaultEnableGpuRasterization
DelayNavigation-Disabled
DownloadAttributionPerformanceTest-DownloadAttributionEnabled
EnableAppContainer-Enabled
EnableMediaRemoting-Enabled_Dogfood
EnableSyncUSSDeviceInfo-Control
EnableWelcomeWin10-Disabled
ExtensionContentVerification-EnforceStrict
ExtensionDeveloperModeWarning-Enabled
HeapCompaction-HeapCompaction
Html5ByDefault-Enabled_Dogfood
HttpFormWarning-Enabled
InstanceID-Enabled
LazyParseCSS-Control
LimitEarlyPreconnects-Control
LoadingWithMojo-Control
MaterialDesignSettings-Enabled_Dogfood
MemoryCoordinatorV0-Default
MidiManagerDynamicInstantiation-Enabled_Dogfood
NTPTilesInInstantService-Enabled
NetDelayableH2AndQuicRequests-Enabled2
NetProxyPreconnects-Enabled_NoControl_Dogfood
NetworkTimeQueries-NetworkTimeQueriesEnabledBackground
NoStatePrefetchValidation-SimpleLoad
OmniboxBundledExperimentV1-Dev_Desktop_NewAnswers_Dogfood
OmniboxEntitySuggestionDogfoodV1-Dev_Desktop_OmniboxEntitySuggestions_Dogfood
PasswordGeneration-Enabled
PasswordManagerSettingsMigration-Enable
PermissionPromptUI-Default
PersistentHistograms-EnabledOnDiskNoStability3
PrefService-Control50
PurgeAndSuspend-Control
QUIC-EnabledAdaptiveTimeLossDetection
RafAlignedMouseInput-Control
ReportCertificateErrors-ShowAndPossiblySend
SRTExperimentalEngineTrial-Control
SRTPromptFieldTrial-SRTCanary
SafeBrowsingScoutTransitionStudy-CanShowScoutOptInGroup2
SafeBrowsingThreatDomDetailsTagAttributes-Control
SafeBrowsingV4LocalDatabaseManagerEnabled-V4Only2
SaveAsMenuText-download
SettingsResetPrompt-Default
SimpleCacheTrial-ExperimentYes
SlimmingPaintInvalidation-Default
SocketReadIfReady-Enabled
StabilityDebugging-Default
SubresourceFilter-EnabledForPhishingSites_Dogfood
SyncUSSAutocomplete-Default
TLS13Negotiation-Enabled
TranslateRankerModel-Query
TranslateServerStudy-NMT
TriggeredResetFieldTrial-On
UKM-Control
UMA-Population-Restrict-dogfood
UMA-Uniformity-Trial-1-Percent-group_73
UMA-Uniformity-Trial-10-Percent-group_05
UMA-Uniformity-Trial-100-Percent-group_01
UMA-Uniformity-Trial-20-Percent-default
UMA-Uniformity-Trial-5-Percent-group_01
UMA-Uniformity-Trial-50-Percent-group_01
V8AsmJsToWasm-Default
V8Ignition-Turbo
VideoBlitColorAccuracy-AccurateVideoBlit
VideoColorManagement-NoColorMgmt
WebFontsInterventionV2-Control-1
WebRTC-BweTrendlineFilter-Control
WebRTC-SimulcastScreenshare-Control_Dogfood
YieldBetweenContentScriptRuns-Control


Of these, BrowserSideNavigation-Enabled_50 stands out.

Is there a Chrome flag to disable PlzNavigate to confirm? I can still repro atm :)

.1 is just SyzyAsan, and shouldn't be relevant.

Let me try with --enable-browser-side-navigation and see if that breaks it for me.

Doesn't seem to repro with --enable-browser-side-navigation for me on 3067.1.

Scratch that, it *does* repro with --enable-browser-side-navigation. Just not 100% of the time maybe (?)

This happens every single time on macOS and still persists with Chrome v.  59.0.3067.0 (Official Build) canary (64-bit)...
Thanks!

I've tried reproducing on trunk on Linux and everything was working fine. Ryan and Scott, could you check if it's also failing on trunk, or just on Canary? Thanks!

My Windows 8.1 64bit, dev version 59.0.3063.4 also has this issue.

Opening PDF link in current tab does not navigate to the PDF URL (but triggers page unload, e.g. navigation confirmation prompt) and opening in a new tab displays blank page.

If this is --enable-browser-side-navigation related, there may be nothing to bisect, since all one will find is the flag got turned on.

If this happens on Canary but not trunk with --enable-browser-side-navigation turned on, then maybe a reverse bisect can identify what fixed the problem in between.

Tested this issue on Windows 10 with chrome #59.0.3068.1

Able to reproduce the issue on canary build #59.0.3068.1, but not on the canary equivalent build #59.0.3068.1

Attaching the screen-cast for reference.

Unable to bisect this issue, since it exists only on canary builds, removing "Needs-bisect" label.

Thank You...

Deleted: Issue 709771.mp4 2.7 MB

	Issue 709771.mp4 2.7 MB View Download

Now that 59.0.3067.0 has trickled down to the dev channel, I can also reproduce this behavior on Linux (Fedora 25).


Google Chrome	59.0.3067.0 (Official Build) dev (64-bit)
Revision	e2ed4b4539b7a50d8be892e4437897b18c181c91-refs/heads/master@{#463157}
OS	Linux
JavaScript	V8 5.9.195
Flash	25.0.0.152 /home/[redacted]/.config/google-chrome-unstable/PepperFlash/25.0.0.152/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3067.0 Safari/537.36
Command Line	/usr/bin/google-chrome-unstable --user-data-dir=/home/[redacted]/.config/google-chrome-unstable --force-device-scale-factor=2 --user-data-dir=/home/[redacted]/.config/google-chrome-unstable --flag-switches-begin --flag-switches-end
Executable Path	/opt/google/chrome-unstable/google-chrome-unstable

I also seem to have the BrowserSideNavigation:Enabled_50 finch flag.

Have the same issue on Mac 10.12.4
Google Chrome	59.0.3067.0 (Official Build) dev (64-bit)
Revision	e2ed4b4539b7a50d8be892e4437897b18c181c91-refs/heads/master@{#463157}
OS	Mac OS X
JavaScript	V8 5.9.195
Flash	25.0.0.152 /Users/xinyang/Library/Application Support/Google/Chrome/PepperFlash/25.0.0.152/PepperFlashPlayer.plugin
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3067.0 Safari/537.36
Command Line	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -psn_0_40970 --restore-last-session --flag-switches-begin --enable-offline-auto-reload --show-saved-copy=secondary --flag-switches-end
Executable Path	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome

PDFs can be downloaded by checking 'Open PDFs using a different application' in chrome://settings/content/pdfDocuments.

Looks like this got fixed in Version 59.0.3071.0 (Canary, 64-bit, macOS Sierra 10.12.5 Beta 2), I think it should all be good...
Could anyone confirm this?

Thanks!
Sid.

No, it's likely you were opted out of the trial. I can confirm 59.0.3071.0 is still failing when browser-side navigation is enabled.

Ok so I can reproduce on Dev Linux reliably, however it doesn't reproduce on trunk. Which is weird. I'm going to get a trace, to try to figure out what is going on.
As far as I can see, the navigation starts but it is cancelled before commit.

Based on the trace, we do request the pdf successfully, (and reach the OnResponseStarted point). However, the navigation is then cancelled and ends with a net::ERR_ABORTED.
The cases where this can happen are the following:
- a new navigation started.
- the ContentBrowserDelegate decided to cancel a transferring navigation.
- the navigation was a 204/205 (I checked it wasn't).
- a NavigationThrottle cancelled the navigation in OnresponseStarted (I checked and there doesn't seem to be any throttle that cancels navigations at that time).

Next, I'll try adding some dumps in the code in order to get a better idea of where this is coming from.

Yes, you guys were correct. It's back with the following Chrome Canary version:
Google Chrome	60.0.3073.0 (Official Build) canary (64-bit)
Revision	aadb33c433f1cf2eb17e4862215c9857c7e26dd1-refs/heads/master@{#464873}
OS	Mac OS X
JavaScript	V8 6.0.3
Flash	25.0.0.156 /Users/Siddhant/Library/Application Support/Google/Chrome Canary/PepperFlash/25.0.0.156/PepperFlashPlayer.plugin
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3073.0 Safari/537.36
Command Line	/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary --no-startup-window --flag-switches-begin --enable-md-feedback --enable-md-policy-page --enable-message-center-always-scroll-up-upon-notification-removal --enable-tab-audio-muting --secondary-ui-md --show-saved-copy=primary --enable-features=MaterialDesignBookmarks,MaterialDesignExtensions,MaterialDesignHistory,MaterialDesignSettings --disable-features=NativeNotifications --flag-switches-end

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/70fd878b6b7abc27c01a68f35b82bee5f51ba03e

commit 70fd878b6b7abc27c01a68f35b82bee5f51ba03e
Author: clamy <clamy@chromium.org>
Date: Tue Apr 18 23:20:12 2017

PlzNavigate: add dump to understand pdf navigation cancellation

This CL adds a DumpWithoutCrashing to try to understand why navigations
to pdf are cancelled when PlzNavigate is enabled.

BUG= 709771 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2823613002
Cr-Commit-Position: refs/heads/master@{#465418}

[modify] https://crrev.com/70fd878b6b7abc27c01a68f35b82bee5f51ba03e/content/browser/frame_host/navigation_request.cc

This doesn't seem to be purely PlzNavigate related, as I've tried several different machines and Chrome versions and I couldn't reproduce it at all. I only managed to get one of my coworkers to repro it, but couldn't collect as much data as I needed before they left for the day.

We have started receiving reports from the DumpWithoutCrashing. So far, we have:
- 9 cancellations coming from NavigationRequest::OnWillProcessResponseChecksComplete (https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_request.cc?type=cs&q=content::NavigationRequest::OnWillProcessResponseChecksComplete&l=806) -> this either corresponds to 204/205 or a NavigationThrottle cancelling the request.
- 486 cancellations correspond to a cancellation from the network stack via a call from NavigationURLLoaderImpl::OnRequestFailed.

I think this is linked to the interaction between NavigationresourceHandler and InterceptResourceHandler. InterceptResourceHandler does not expect its next handler to pause the navigation in OnWillProcessResponse, so when the navigation is a stream or a download, so we do not pause the load while waiting for the UI checks to execute. In particular, if one NavigationThrottle pauses the navigation we still have a NavigationRequest for it. When the load finishes, the InterceptResourceHandler behavior is to cancel its old handler, as it does not expect it to be still present. If we still have a NavigationRequest on the UI thread, this will abort it. In particular, this will prevent the payload that is supposed to be delivered to the renderer to reach the renderer.

For the next step, we should update the InterceptResourceHandler and NavigationResourceHandler so that they actually pause the request while NavigationThrottles get to execute. We should also pay attention to the fact that we may have to skip executing some of the throttles (eg AncestorNavigationresourceThrottle) when the navigation turns out to be a stream or a download. Currently this only works because we cannot cancel it in the net stack. If we pause it, we'll be able to.

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

This issue is marked as a release blocker with no OS labels associated. Please add an appropriate OS label.

All release blocking issues should have OS labels associated to it, so that the issue can tracked and promptly verified, once it gets fixed.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Moving the release block to M60. We are not experimenting with PlzNavigate on M59 beta and stable, so there is no reason to block M59 on this PlzNavigate specific issue.

There have been similar reports against M56 in  Issue 697574 . Is it possible that this could be the same root cause? It was reproducible with M59 on a colleague's machine, but I wasn't able to confirm that it was caused by browser-side navigation. (It was working in one user-data-dir that was opted in to the experiment.)

Reproducible on Chrome 59.0.3071.8/CrOS 9460.4.0 - Enguarde. 
There is no "Plugin:Chrome PDF Viewer" on "Task Manager" while opening the PDF files/links. 

Deleted: 2017 Form W-4.pdf 83.0 KB

2017 Form W-4.pdf 83.0 KB Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a7629595cadb7b48331e9ae449d715693ac8e385

commit a7629595cadb7b48331e9ae449d715693ac8e385
Author: clamy <clamy@chromium.org>
Date: Fri Apr 21 13:06:12 2017

Revert of PlzNavigate: add dump to understand pdf navigation cancellation (patchset #2 id:20001 of https://codereview.chromium.org/2823613002/ )

Reason for revert:
Reverting since we got the data needed.

Original issue's description:
> PlzNavigate: add dump to understand pdf navigation cancellation
>
> This CL adds a DumpWithoutCrashing to try to understand why navigations
> to pdf are cancelled when PlzNavigate is enabled.
>
> BUG= 709771 
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
>
> Review-Url: https://codereview.chromium.org/2823613002
> Cr-Commit-Position: refs/heads/master@{#465418}
> Committed: https://chromium.googlesource.com/chromium/src/+/70fd878b6b7abc27c01a68f35b82bee5f51ba03e

TBR=nasko@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 709771 

Review-Url: https://codereview.chromium.org/2837573002
Cr-Commit-Position: refs/heads/master@{#466320}

[modify] https://crrev.com/a7629595cadb7b48331e9ae449d715693ac8e385/content/browser/frame_host/navigation_request.cc

@kbr: I think this is different from  Issue 697574 . In this issue, the users would see a black box, in this one users do not navigate away from the page.

Just to update the behavior on build-60.0.3080.5:
1.Issue working as expected on Windows 7 & Mac 10.12.4 using chrome-60.0.3080.5.
Observed user able to navigate to all the pdf files in the URL's provided in comment#0.

2. No action observed upon clicking pdf files in the URL's provided in comment#0 on Linux Ubuntu 14.04 OS.

clamy@, Could you please confirm is this blocking today's Dev build-60.0.3080.5 as it is labeled as "Proj-PlzNavigate-Blocking" and still issue seen on Linux OS.

Please find the attached screencast on Linux  & WINDOWS.
Thanks in advance..!

Deleted: 709771-Issue on Linux.mp4 2.8 MB

	709771-Issue on Linux.mp4 2.8 MB View Download

Deleted: 709771.mp4 3.7 MB

	709771.mp4 3.7 MB View Download

Correction in above comment.

Issue working as expected on Linux Ubuntu -14.04 also using 60.0.3080.5.As it is working as expected on Windows, Mac & ubuntu ,adding TE Verified labels.

Thank you..!

@Comment 37: Removing TE-Verified, because it appears the Browser navigation Finch experiment was not enabled for the "Verified" case. For that case, it's expected to work, but when the browser-side navigation is enabled, it may have issues. Just wanting to make sure for TE that part is clear. (The experiment was/is "BrowserSideNavigation-Enabled_50")

I'm experiencing an issue where no PDFs loading and believe this is related. By using --disable-features=browser-side-navigation PDFs start loading again. I spoke with nasko@ and he thinks that this may be interacting with SafeBrowsingV4LocalDatabaseManagerEnabled-V4Only2, which is also enabled.

Full variations are here: https://paste.googleplex.com/6464642721251328

A little more poking and I've found that this reproduces the problem:

--enable-features=browser-side-navigation,SafeBrowsingV4LocalDatabaseManagerEnabled,SafeBrowsingV4OnlyEnabled

And this does not repro:

--enable-features=browser-side-navigation --disable-features=SafeBrowsingV4LocalDatabaseManagerEnabled,SafeBrowsingV4OnlyEnabled

Thanks #c40 for the repro flags! I can repro consistently with this set and I've confirmed that clamy@'s CL (https://codereview.chromium.org/2847443002/) does indeed fix the issue.

Thanks nasko & rsesek for confirming that this was the indeed the problem!

 Issue 697574  has been merged into this issue.

I just posted an update on  issue 697574 , which I don't think is actually the same as this one. In this case, we won't even attempt to load the PDF document, so the user will see no transition. In  issue 697574 , the original report is that the PDF is loaded, but it does not display. In addition, PlzNavigate was not put into field trials until M59, which is much later than the reports indicate (M56).

Seeing same issue still, PLEASE FIX:


Google Inc.
Copyright 2017 Google Inc. All rights reserved.
Google Chrome	57.0.2987.133 (Official Build) (64-bit)
Revision	ec33cd0c06881d919ac0de419d829ad914e0be8f-refs/branch-heads/2987@{#887}
OS	Mac OS X 
JavaScript	V8 5.7.492.71
Flash	25.0.0.148 /Users/cballenger/Library/Application Support/Google/Chrome/PepperFlash/25.0.0.148/PepperFlashPlayer.plugin
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Command Line	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --flag-switches-end
Executable Path	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome
Profile Path	/Users/cballenger/Library/Application Support/Google/Chrome/Default
Variations	ea8deb27-3d47f4f4
3095aa95-3f4a17df
7c1bc906-f55a7974
2a33b90e-e7b70917
ba3f87da-b4a760c3
cf558fa6-48a16532
58aac55e-3f4a17df
f3499283-f94608c8
31362330-3f4a17df
c70841c8-a2567007
349d561b-3f4a17df
9e201a2b-26bbc519
6eb432aa-ca7d8d80
5274eb09-3f4a17df
684d1cdf-51126808
9773d3bd-ca7d8d80
b22b3d54-3d47f4f4
2e109477-ca7d8d80
165e16d1-3f4a17df
9e5c75f1-c16ec2e6
6b121ae7-ca7d8d80
f79cb77b-3d47f4f4
b7786474-d93a0620
23a898eb-ca7d8d80
48bd06b2-f23d1dea
4ea303a6-fea2917d
3d7e3f6a-2eb01455
9736de91-ca7d8d80
64005e71-4ad60575
f069f10b-803f8fc4
69bf80fa-91c810ef
867c4c68-3f4a17df
b2f0086-93053e47
7fc902e8-ca7d8d80
f11cb941-11910166
f47ae82a-86f22ee5
3ac60855-486e2a9c
f296190c-f9f7acb5
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-bd104136
e7e71889-e1cc0f14
828a5926-ca7d8d80

Deleted: net-internals-log.json 237 KB

net-internals-log.json 237 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5

commit ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5
Author: clamy <clamy@chromium.org>
Date: Tue May 02 17:13:57 2017

PlzNavigate: make NavigationResourceHandler a LayeredResourceHandler

This CL makes NavigationResourceHandler a LayeredResourceHandler and
moves it just after the MimeSniffingResourceHandler. In PlzNavigate, the
ordering of ResourceHandlers in navigation is the following:
- ThrottlingResourceHandler
- MimeSniffingResourceHandler
- ThrottlingResourceHandler (no NavigationResourceThrottle)
- InterceptingResourceHandler
- NavigationResourceHandler: interacts with the UI thread & writes the
response in a stream.

After this CL, the ordering of ResourceHandlers will be the following:
- ThrottlingResourceHandler
- MimeSniffingResourceHandler
- NavigationResourceHandler: interacts with the UI thread
- ThrottlingResourceHandler (no NavigationResourceThrottle)
- InterceptingResourceHandler
- StreamResourceHandler: writes the response in a stream.

The reason is two-fold. First, it better matches the ordering of
ResourceHandlers in the current navigation architecture, which is:
- ThrottlingResourceHandler
- MimeSniffingResourceHandler
- ThrottlingResourceHandler with a NavigationResourceThrottle (interacts
with the UI thread)
- InterceptingResourceHandler
- AsyncResourceHandler

In particular, this ensures that the NavigationThrottles will be
executed before teh second-round of ResourceThrottles both in
PlzNavigate and in the current architecture.

Second, moving NavigationResourceHandler before the
InterceptingResourceHandler allows to properly pause downloads & stream
requests while we execute the NavigationThrottles on the UI thread. This
was not possible before because InterceptingResourceHandler does not
expect its next handler to pause the request in OnResponseStarted. Not
pausing it is causing race conditions with the processing of the
navigation on the UI thread.

BUG= 709771 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2847443002
Cr-Commit-Position: refs/heads/master@{#468692}

[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/loader/navigation_resource_handler.cc
[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/loader/navigation_resource_handler.h
[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/loader/resource_dispatcher_host_impl.h
[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/loader/resource_dispatcher_host_unittest.cc
[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/loader/stream_resource_handler.cc
[modify] https://crrev.com/ea2f911cf6b0b023ff26e17bb9e57c871c8f52f5/content/browser/loader/stream_resource_handler.h

The CL landed in #46 should have fixed the issue.

verified this issue on Win 10, Mac 10.12.4 and Ubuntu 14.04 with chrome #60.0.3088.3

Able to Navigate to the pdf files for provided url in comment #0 as expected, Hence adding TE-Verified labels.

Apologies, applied the wrong component in bulk.