DevTools: add option to pause extension content scripts during performance profiling |
|||||
Issue descriptionChrome Version: 59.0.3071.115 (Official Build) (64-bit) What steps will reproduce the problem? (1) Attempt to profile any site with costly Chrome extensions enabled (e.g AdBlock or uBlock Origin) (2) Read back the trace. Timeline/Performance panel results can be heavily skewed by these extensions (3) Only manually disabling the extensions or running in a fresh Chrome profile work around this issue. Most developers we speak to are not doing this step nor are aware of the impact it can have on traces. What is the expected result? Chrome extensions do not impact traces because ideally DevTools would disable them when profiling. Lighthouse uses a trick to disable extensions before running, runs audits and then re-enables these extensions after. It would be highly valuable if DevTools could do something similar: https://github.com/GoogleChrome/lighthouse/pull/1492 Caveat: I understand that DevTools itself has DevTools extensions that could be included in this group. As much as possible, if we could disable all extensions that can impact a trace that would be appreciated. Inspiration for this feature request: https://twitter.com/_developit/status/883381308919099392
,
Jul 11 2017
Simply profile in an incognito window.
,
Jul 11 2017
,
Jul 11 2017
FWIW, straight out disabling extensions is dangerous. For example, I use Great Suspender to suspend inactive tabs, and when that extension is disabled, I lose all my tabs. :) However there may be some opportunities where we could suspend Extensions from injecting any content scripts while we are profiling.
,
Jul 12 2017
Rather than outright disabling extensions, could this be done similar to how certain pages (chrome:// pages, Chrome Web Store, etc) don't allow extensions to operate on them? Extension state wouldn't be lost, other tabs wouldn't be affected, and extensions wouldn't need to be changed since they already need to handle being invoked on pages they aren't allowed to touch. It would probably require a page refresh for extensions that have already injected content into the page, but it could cover the 80% use case (page-load traces; extensions using only APIs like webRequest) without a reload.
,
Dec 5
,
Dec 20
,
Dec 20
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by jaffathe...@gmail.com
, Jul 11 2017