Chrome Extensions API Message Passing Time Lag on First Response to Message from Content Script
Reported by
thomasga...@gmail.com,
Oct 26
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Set up a basic extension with background page and content script. 2. Have the content script be loaded at document_start and get the content script to send a basic 'hello world' text message to the background page and wait for a response. 3. Add performance timing measurements to see how long it takes for the first content script message to receive a 'hello back' text response from the background page. What is the expected behavior? I would expect the messaging functions to be consistent, whether it is the first message sent or one of many. I understand that the extensions API needs time to establish a connection to the content script but the performance is bad. Performance of subsequent messages after the first is good, about 30-40 ms to get a basic response, no matter what the other workload of the background page might be. What went wrong? On average. the first message sent by the content script takes 150-200 ms to receive a response. This kind of lag makes it very difficult to manage operations that require co-ordination between the content script and the background page when interacting with a fast moving web page. Later messages are, without exception, fast (30-40 ms). Did this work before? N/A Does this work in other browsers? N/A Chrome version: 69.0.3497.100 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Oct 27
Without an actual extension and detailed steps-to-reproduce the obvious guesses would be: * you're using an event page (a non-persistent background page) which takes at least 100ms to wake up. * the web page process is busy doing something - for example if the content script loads at document_start, the page is being loaded and constructed so the content script can't receive a message during that time. Also, 30-40ms seems too long for the subsequent comm cycles - should be just a few ms for small message payloads.
,
Oct 28
Hi thanks for getting back. I'm not using a non-persistent background page. That's a good guess about the content script being unable to process the response because the web page process has got so much going on. I was getting those timings from a React JS page which is obviously working hard to construct the HTML. I've check on other pages and the response time drops to a much more manageable 40ms. Thanks for the typical comms cycle info.
,
Oct 29
,
Oct 30
Thanks for filing the issue. @reporter: Could you please provide a sample file of extension or URL that reproduces the issue so that it would be really helpful for triaging the issue.
,
Oct 30
I think you should close this bug report. The helpful comments from woxxom@gmail.com helped me get to the bottom of what was going on. Thanks.
,
Oct 30
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
,
Nov 15
As per comment# 6 from the reporter, closing this issue and marking it as Won't fix. Thanks! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by thomasga...@gmail.com
, Oct 27