Issue metadata
Sign in to add a comment
|
WebExtension contentscripts cannot always load before page scripts
Reported by
dan.fin...@consensys.net,
Apr 26 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. Launch Chrome 2. Install the MetaMask browser extension. 3. Load https://flyswatter.github.io/chrome-contentscript-bug-reproduction 4. The page messages will describe the problem, you can read the source to see exactly how. What is the expected behavior? WebExtensions that define a contentscript with a manifest.json file with a run_at key set to “document_start” should run before any DOM is injected and before any page scripts are run, according to Google documentation: https://developer.chrome.com/extensions/content_scripts What went wrong? Instead there seems to be a race condition, where the page’s scripts and DOM elements are loaded at the same time as the browser extension’s inpage script, and so our API consumers are forced to do strange hacks like waiting arbitrary amounts of time for the extension to actually load. Did this work before? No Does this work in other browsers? N/A Chrome version: 57.0.2987.133 Channel: n/a OS Version: OS X 10.12.4 Flash Version: Thank you very much for your time! MetaMask is trying something slightly rare, experimenting with offering an extended browser API surface to web developers, and so the ability to inject our API before pages load is critical to creating a WebExtension-extendable web.
,
Apr 27 2017
YES, Thank you Woxxom, I think you've hit the nail on the head. My test is not really measuring the contentscript timing, but the timing of a script that it inserts into a webpage. Thank you so much for the issue link, I'll be following it up thoroughly tomorrow, I feel like I've found "my people" (extension developers who just want to inject a script tag early).
,
Apr 28 2017
,
Jul 21 2017
dan.finlay@ - Could you please upgrade chrome to latest stable #59.0.3071.115 and please let us know if the issue still persist or not. Thanks...!!
,
Jul 21 2017
Thank you so much for giving this some time and effort, I can't tell you how giddy I got when I saw that there was a new theory, and a new fix in production! I've updated, and unfortunately, following the steps above, continued to reproduce the bug. In case there were other cases that were fixed, I asked a few developers using our API if this has improved the effect, and so far, the people who have been able to reproduce the issue have continued to. It does very much sound like you were on the right path, so I really don't know what might be missing. Thanks a ton for your time.
,
Jan 22 2018
Mac triage: marking as duplicate of issue 634381, which seems to be the same underlying issue but more with a more detailed report. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by woxxom@gmail.com
, Apr 27 2017