New Creds: chrome / Chromepass!

Above credentials and the one in C#1 doesn't seem to work. Could you please recheck this, also re-share the credentials only if its fine to share. Please attach the crash id, if the tab hang results in renderer crash and generate any crash id under chrome://crashes. 

Sorry use site https://smart911.rave411.com/rcv/login with same creds.

Also, please enable the chrome option "Download PDF files instead of automatically opening them in Chrome" under PDF documents.

1)When in click on a ticket from the ticket list on the left side of the page.
2)This will open a smartlet in the middle of the page. (Header of smartlet is Smart911 Profile.
3)On the addresses section of the smartlet, click on first address (74 Winslow ave) which will display meta data for that address.
4) Click the "view uploads document" link next to the label "Building Plans", this will download a pdf file.
5)Click the large "CLOSE DOCUMENT" button.

6 Repeat steps 4 and 5 six more times until it hangs the page and you see "waiting for available socket..." in lower left corner of the page.
7. At this point you cannot even logout of the page using the "log out' button at the far right of the menu bar at the top of the page.

See attached screenshots for help navigating app and the socket state during this failing condition. The worked in chrome 67.x.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Login credentials don't work on either URL.
Can you collect a net-log covering a "waiting for available socket" event and attach to this bug?
http://dev.chromium.org/for-testers/providing-network-details

Ok, I captured the failure as detailed above. See screenshot of "waiting for available socket..." Also see attached log file from capture.

Deleted: chrome-net-export-log.json 20.1 MB

chrome-net-export-log.json 20.1 MB Download

Deleted: Sockets2.png 693 KB

	Sockets2.png 693 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Requests end up stuck on delegate MojoAsyncResourceHandler, and after we get six of them stuck, the next request hits SOCKET_POOL_STALLED_MAX_SOCKETS_PER_GROUP.

Adding loader and PDF components as this is likely an issue above the network stack in the loader or PDF logic.

Tested this issue and unable to reproduce the issue on reported chrome 68.0.3440.84 and latest chrome using Windows 10.Attaching scree shoot for reference.
Steps:
-----
1. Launched reported chrome
2. Navigated to given URL AS per Comment #4 " https://smart911.rave411.com/rcv/login "
As we are getting error like "This site can’t be reached"

@pauljensen: As per comment #9 and comment #10 Requesting you to please have a look into it for further inputs on it.

Thanks..!

Deleted: 872284.PNG 20.0 KB

	872284.PNG 20.0 KB View Download

Not sure why you cannot get to the website.

Deleted: site.png 48.0 KB

	site.png 48.0 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

As per comment #13, As we are unable to open this site from our end (" https://smart911.rave411.com/rcv/login ") routing this to in-house team to check this in their n/w whether " https://smart911.rave411.com/rcv/login " is opens or not. Hence adding TE-NeedsTriageFromHYD label to it.

Thanks..!

Tested the issue on windows 10 using reported version #68.0.3440.84 & latest stable #68.0.3440.106.Unable to reproduce the issue as per steps mentioned in comment#4 (i.e; No tab hang is seen and was able to logout successfully).

Attaching screen-cast for reference.

@Reporter: Could you please check by update chrome to latest stable #68.0.3440.106 and let us know if issue persists.

Thanks!

Deleted: Not tab hang is seen.webm 13.5 MB

	Not tab hang is seen.webm 13.5 MB View Download

Still happening in latest stable #68.0.3440.106. After trying opening 7+ PDF files as demonstrated in your video, try and logout using the logout button in the top-right of the page. It's hung. Also see chrome://net-internals/#sockets where you can see there are 6 sockets open. See screenshots.

Deleted: app.png 166 KB

	app.png 166 KB View Download

Deleted: app2.png 15.9 KB

	app2.png 15.9 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Tested this issue on Windows 10 with chrome #68.0.3440.106 as per steps mentioned in comment #4 and observed that at step 4 i was unable to download the pdf file

Attaching the screen-cast for reference.

patrickflaherty1946@ Could you please look into it and let us know any steps i missed while testing the scenario.

Deleted: 872284.mp4 2.2 MB

	872284.mp4 2.2 MB View Download

Ok, sorry for the delay. We have another issue with Chrome 68.x where the PDF file does not get downloaded as demonstrated in your video above. It seems our content security policy is balking at the download. See attached screenshot.

Should open a different bug for this?

Deleted: Chrome-CSP.png 30.0 KB

	Chrome-CSP.png 30.0 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Content-Security-Policy: default-src 'self'; font-src 'self' data: *.gstatic.com; frame-src 'self' data: blob: www.nbcnews.com www.youtube.com; connect-src 'self' *.mapbox.com wss://smart911.rave411.com translate.googleapis.com; child-src 'self' *.youtube.com wss://smart911.rave411.com; object-src 'self' blob: data: smart911.rave411.com; style-src 'self' 'unsafe-inline' *.googleapis.com; img-src * blob: data: *.mapbox.com *.rave411.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.google.com *.google-analytics.com *.googleapis.com *.mapbox.com www.sc.pages05.net

The CSP issue is likely Issue 271452

The original issue is most likely related to the PDF engine, so removing the Internals>Network label for now.

Ok, the Content-Security-Policy issue is resolved. So can you now try the steps to reproduce the original problem around the sockets? i.e. download the PDF 6+ times as described above. The PDFs should actually download not that the Content-Security-Policy issue is resolved.

After 6+ PDFs are attempted you should see the 6 sockets open using chrome://net-internals/#sockets and the the app showing "Waiting for available socket..." in the lower-left corner.

Deleted: Sockets3.png 49.6 KB

	Sockets3.png 49.6 KB View Download

Deleted: app.png 166 KB

	app.png 166 KB View Download

Ran into the same issue today, but only with the option "Download PDF files instead of automatically opening them in Chrome" turned on. After opening a bunch of files that way, I can observe the open sockets as described above and the tabs hanging.

Are you using a Content Security Policy in the response?

We do not. These are the response headers:

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 360087
Content-Type: application/pdf
Server: 
X-Pli-Server-Version: 2.6.6.836
Content-Disposition: inline; filename="abc.pdf"; name="abc"
Strict-Transport-Security: max-age=31536000
Date: Fri, 24 Aug 2018 21:10:07 GMT

My fix was changing one of my CSP lines:
From:
object-src 'self' blob: data: mydomain.com; 
To:
object-src 'self' 'unsafe-inline' blob: data: mydomain.com; 

Adding 'unsafe-inline'.

Tested the issue on windows 10 using 68.0.3440.106 as per c#4 & c#26 and unable to reproduce the issue from TE end(i.e, observed that pdf's not getting downloaded and no waiting for available sockets message is seen-refer c#13,#17,#21).Hence removing Needs-bisect label for now and please feel free to add if required.

Attaching screen-cast for reference.

Thanks!

Deleted: 872284_no hang & waiting message.mp4 6.4 MB

	872284_no hang & waiting message.mp4 6.4 MB View Download

Please observe Dev Tools (F12) Console while opening PDF.

Thank you,
Patrick

Tested this issue on Windows 10 & debain using 68.0.3440.106. Able to reproduce i.e,waiting for available sockets message is seen after multiple trials(>10+) to download pdf.

Note: Able reproduce this when dev tools console is open.

Manual bisect results,
Good-67.0.3396.0
Bad-68.0.3397.0

Unable to provide tool bisect as this issue is reproducible only when pdf's are not downloaded due to content security policy as mentioned in c#22. While performing tool bisect we are getting all good build(i.e all pdf's are getting downloaded) even increasing the range doesn't help.

Hence marking this issue as untriaged to get this addressed by dev team.

Thanks!

Does this issue still happen in Chrome 69?

The logins given initially no longer works.

I'm curious, is the server sending the right Content-Length in the response headers?

Creds should still work as I just tested them.

Creds: chrome / Chromepass!

Yes, it still happens in Chrome 69.

The answer to comment 37 is if I roll back to build 67.x or earlier, it works.

I'd also like to mention that we have the exact same issue with Chrome 68 and it seems worse with 69.  After 6 PDFs are generated on our internal webapp, the "waiting for available socket" issue occurs.  The only way to reset is to flush the sockets or close all browser sessions.

re: comment 38: I think the confusion w.r.t. comment 37 is because I used the URL in the original bug report and not the one in comment 4. Now I can successfully login, but there are no tickets in the webapp. When I created some tickets, they are "not mapped" so I can't find a way to open the "smartlet".

It would be really helpful to make a simpler test case to make reproducing this issue easier.

 thestig@chromium.org, I apologize as the ticket expired. The ticket is back and this is the easiest way too demo this problem as there are not many steps.

Thank you,
Patrick

Thanks, now it is possible to reproduce the issue. Assuming I bisected correctly, the regression range is https://chromium.googlesource.com/chromium/src/+log/99f4e7a3..e8d15ffe, so I suspect this is due to r543428.

Since the built-in PDF Viewer is turned off in the scenario that hits this issue, it is not involved at all.

thestig@ didd you had any time looking into this ?
It's still happening in 70.0.3538.77 and 72.0.3599.0

this issue is happening also for a customer:
case: 17035441
customer info:
https://drive.google.com/open?id=1mHIAtbra3rS69_scjXD6HA7m8BCd7adv_2BzYxM3g8c
net-export, screenshot: https://drive.google.com/open?id=1EHIglXhBdjsT0kXbgT4gRFKPiHXqTa4M

marcore: The issue is not in a component that I'm responsible for. See comment 44.

We're running into the same problem. We're only noticing it when the pdf has `Content-Disposition: inline` and the Chrome setting "Download PDF files instead of automatically opening them in Chrome" is enabled

Triager here. arthursonzogni@ would you mind looking into the issue per c#44?

I just ran into this exact same issue as well.

Sorry, I missed this issue. I will try to triage.
I can't reproduce. Here is a video.

@testig (or anyone else): Am I doing the right thing to reproduce?

Deleted: out-46.ogv 6.1 MB

	out-46.ogv 6.1 MB View Download

arthursonzogni@ I was able to reproduce on OS X as shown in the attached video using a simple localhost flask application, which is also attached. As well as the test pdf I used, but any old PDF should do.

Deleted: app.py 410 bytes

app.py 410 bytes View Download

Deleted: test.pdf 6.8 KB

test.pdf 6.8 KB Download

Deleted: 1.mp4 5.0 MB

	1.mp4 5.0 MB View Download

Thanks!

Does it reproduced on your side on:
https://test-bug-872284.glitch.me/
?

Okay I can reproduce. I am taking a look.

+mmenke@ FYI

Maybe the download path do not release properly some net/ object.
It only reproduce when I disable the NetworkService BTW.

In the testcase, there is no need to have nested <object></iframe>.
I am using:
~~~
#!/usr/bin/env python
from flask import Flask, Response
app = Flask(__name__)


@app.route('/')
def home():
  return """
  <iframe src="test.pdf"></iframe>
  <iframe src="test.pdf"></iframe>
  <iframe src="test.pdf"></iframe>
  <iframe src="test.pdf"></iframe>
  <iframe src="test.pdf"></iframe>
  <iframe src="test.pdf"></iframe>
  <iframe src="test.pdf"></iframe>
  <iframe src="test.pdf"></iframe>
  """

@app.route('/test.pdf')
def pdf():
    with open('test.pdf', 'rb') as fp:
        return Response(fp.read(), mimetype='application/pdf')

~~~

Since this is only happening for downloading PDFs, this is almost certainly an issue in the PDF or downloads code either not reading from live requests, or not cleaning up after itself (If the requests are complete, that shouldn't be the issue, though, so most likely the first).  Alternatively, if the PDFs haven't been completely received from the server yet, this is expected behavior.

Not sure it was right to remove the PDF component - PDFs have their own unique download path.

I think it work well without the NetworkService because there is no need to wait for URLLoader::ProceedWithResponse(). It looks like the navigation request fails to call it at some point.

+Navigation.
+CC clamy@ / nasko@ FYI.

Erm...wait...does it work with the network service, or without it?  #59 and #56 seem to say opposite things?

It works with the NetworkService sorry! (trust #59, not #56)

I think I'm on to something. I hope to find the bug in less than 1 h before leaving.

> Does it reproduced on your side on:
> https://test-bug-872284.glitch.me/

Yes, the issue came about after a few refreshes there.

> Yes, the issue came about after a few refreshes there.
Okay nice to know. On my side I wasn't able to reproduce with it. With your python script it reproduce all the time.

Note: I didn't finished investigating, but it might be about the PDFIFrameNavigationThrottle.

> Okay nice to know. On my side I wasn't able to reproduce with it. With your python script it reproduce all the time.

I just verified again. On that page, I had to do 2 hard refreshes on the page. Only doing a regular refresh did not trigger the issue. I never actually had to click "open" on any of the pdfs.

I found the issue.

The PDFIframeNavigationThrottle cancel the download.

But in content/browser/loader/resource_loader.cc, the cancellation is ignored:
~~~
void ResourceLoader::CancelRequestInternal(int error, bool from_renderer) {
  DVLOG(1) << "CancelRequestInternal: " << request_->url().spec();

  ResourceRequestInfoImpl* info = GetRequestInfo();

  // WebKit will send us a cancel for downloads since it no longer handles
  // them.  In this case, ignore the cancel since we handle downloads in the
  // browser.
  if (from_renderer && (info->IsDownload() || info->is_stream()))
    return;
~~~

So the loader stay alive and wait.. wait.. forever.

I am taking a look to see what can be done here.

+CC yhirano.

I made regression test here: https://chromium-review.googlesource.com/c/chromium/src/+/1348036

I also made an attempt to fix the bug. It will probably not pass the try-bots though.

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

commit d814333c7674bcc0ff8165d9e5146092649306f1
Author: Arthur Sonzogni <arthursonzogni@chromium.org>
Date: Thu Nov 29 13:38:00 2018

Fix network socket starvation.

This fixes  https://crbug.com/872284  and adds a regression test.

The bug can be triggered when the PDFIframeNavigationThrottle cancels the
PDF download. There was some code in ResourceLoader made to ignore the
cancellation. It causes the net socket to never been released. Only 6
network socket can be used on a website, so there was some kind of
resource starvation.

Bug:  872284 
Change-Id: I9fcaf8da409da38e0cb4b2e9c6ad57bb2fab911c
Reviewed-on: https://chromium-review.googlesource.com/c/1348036
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#612172}
[modify] https://crrev.com/d814333c7674bcc0ff8165d9e5146092649306f1/content/browser/loader/mojo_async_resource_handler.cc
[modify] https://crrev.com/d814333c7674bcc0ff8165d9e5146092649306f1/content/browser/loader/mojo_async_resource_handler.h
[modify] https://crrev.com/d814333c7674bcc0ff8165d9e5146092649306f1/content/browser/navigation_browsertest.cc

I think this regressed in Chrome 66 and has been fixed today, just in time before M72 branch point.

Since this bug has been here for a few releases, I don't think there is a need to cherry-pick it for M71. Let me know if you think otherwise.

Hello Team,

I just want to know if what version of Chrome were the fix will be available? 


Thanks in advance!

Per Comment 70, we aren't going to backport a fix, so it will be on stable when Chrome 72 makes it to stable, which I believe will be in late January.  The fix is on Canary now, and presumably Dev channel as well.

 Issue 912895  has been merged into this issue.