Issue metadata
Sign in to add a comment
|
Network activity not recorded for certain file downloads
Reported by
stuartm....@gmail.com,
Feb 2 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. New tab 2. Inspect 3. Switch to Network, check Preserve Log and Disable cache 4. Paste http://releases.ubuntu.com/16.04.1/ubuntu-16.04.1-desktop-amd64.iso?_ga=1.28615161.496526627.1477681167 into URL bar, press enter 5. Observe the file download dialog box appears, but no network activity is recorded. 6. Repeat above steps but with https://help.ubuntu.com/lts/serverguide/serverguide.pdf instead. Observe network activity is recorded. What is the expected behavior? Network activity is recorded for ALL network activity. What went wrong? Network activity was not recorded. This appears to happen with file/content types that don't have an app handler set. Did this work before? Yes Chrome version: 55.0.2883.87 Channel: Stable OS Version: Ubuntu 14.04.5 LTS Flash Version: Shockwave Flash 24.0 r0 This thread (https://groups.google.com/a/chromium.org/forum/#!msg/chromium-discuss/nqfg4yYucYs/_V9CwrYAAwAJ) indicates that this is a regression.
,
Feb 3 2017
,
Jul 20 2017
This bug fell off the radar. Can I get a new repro case? Otherwise I am going to close the bug to try and clean my bug list. Thanks!
,
Aug 21 2017
No feedback was received in the last 30 days from reporter "stuartm.coding@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 31 2017
The original repro case still repros. Not sure why this was closed. Just checked with Version 60.0.3112.78 (Official Build) (64-bit)
,
Nov 1 2017
This isn't really a bug per'se. This happens because the renderer did not go away because the navigation request did not commit. Since the request is now handled by the browser (browser process) the attached renderer knows nothing about the download since it has no reason to know about it once the download starts. An easy way to think about it is: * A navigation tried to happen by user. * Navigation failed and instead download the file. * Since it's a navigation we would need to render the file, but it was downloaded instead of committed for rendering. Now we can either show a blank page which is just there because the navigation went to the downloaded file (but there is nothing to render), or we can keep the user looking at what they were looking at. In this case we show the latter. The reason devtools can't show anything is because we don't know about it. If it's important to look at browser and/or all network activity we have chrome://net-internals/ which can display much more info than devtools can, but sadly it's raw data and hard to look at.
,
Nov 8 2017
An easy way to think about it is: * Used did a thing in Chrome that caused network activity * Chrome devtools must show that network activity I don't care about the rendered or the page display; that's not relevant to the issue. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by nhar...@chromium.org
, Feb 2 2017