feature request: Update load status for more than just webRequest (e.g. document_start content scripts)
Reported by
wesam.we...@gmail.com,
Jul 20 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3160.0 Safari/537.36 Steps to reproduce the problem: 1. open really slow loading website What is the expected behavior? show "waiting for <extension name>" while loading What went wrong? nothing.. Did this work before? N/A Chrome version: 61.0.3160.0 Channel: canary OS Version: 10.0 Flash Version:
,
Jul 22 2017
sorry, is this a automated response? this is a feature request.
,
Jul 22 2017
Thank you for providing more feedback. Adding requester "ajha@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 22 2017
useful for seeing, how extensions like ublock and Adblock when intercepting http request how it impacts (slows down) the browsing experience. also in general a good features so users know what are the installed extensions doing, transparency.. this message can be shown when the extension is intercepting I/O (HTTP) or doing I/O (Storage, sync etc.).
,
Jul 23 2017
Chrome doesn't wait for extensions normally. The extensions with persistent background pages that intercept network requests are loaded during the startup of the browser and this is the only case when the browser might need to wait. Also, normally uBlock speeds up loading of pages enormously, e.g. 1 second instead of 5 seconds, which I've witnessed many times over the years I've been using it. You need to present your case by specifying the exact steps needed to reproduce the issue in a pristine new browser profile.
,
Jul 25 2017
Seems this is a feature request,marking it as Untriaged to get more inputs from dev . Thanks..!!
,
Jul 31 2017
,
Aug 4 2017
We actually already do this for webRequest. [1] You can see this if you have a *really* slow webRequest extension. Showing this for every extension action isn't something we'll want to do, since most of them are non-blocking. The other possible place this could make sense is if an extension has a very slow content script running at document_start, which would effectively block page load. Given we already do this in the most egregious case (webRequest), I don't think this is very high priority at the moment. Updating labels and description accordingly. [1] https://chromium.googlesource.com/chromium/src/+/4314fd9c8498473c5e53a529e11d2678bd1a1ea2/extensions/browser/api/web_request/web_request_api.cc#1112
,
Aug 6
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ajha@chromium.org
, Jul 21 2017Components: -UI Blink>Loader
Labels: Needs-Feedback