New issue
Advanced search Search tips

Issue 667787 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

chrome.tabs.onMessage does not receive event

Reported by para.sel...@gmail.com, Nov 22 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.59 Safari/537.36

Steps to reproduce the problem:
1. Load the attached extension into chrome
2. Visit https://www.w3.org/standards/webdesign/
3. Open the developer console for both the page (w3.org) and the extension ("Message passing issue")
4. Make sure "Preseve log" is checked on
5. On the /webdesign/ page, quickly click between the links on the left-hand bar "Web of Devices" and "Web Design and Applications"

What is the expected behavior?
Each time we click a link, we should see the message "content script saw: background script saw: https://www.w3.org/standards/webofdevices/" or "content script saw: background script saw: https://www.w3.org/standards/webdesign/" in the developer console for the page (w3.org).

What went wrong?
When clicking between the links, sometimes no message is reported in the developer console for the page.

Did this work before? Yes 54.0.2840.100

Does this work in other browsers? Yes

Chrome version: 55.0.2883.59  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 23.0 r0

This does not happen for us on all machines. Rather, this seems to reproduce more often on slower machines.

It seems to matter that we click a link that loads in a new page. (Just clicking around on a page does not reproduce the issue.) Not all pages reproduce the issue. We've had the best luck reproducing the issue on simple pages like the one at w3c.org.

Waiting for a few (~30) seconds between clicks sometimes causes the issue to disappear.

The extension console always reports its message "background script saw: <url>". So the failure occurs during round-trip from content script > background script > content script.
 
exampleExtension.zip
1.1 KB Download
It turns out that with this reduced test case the issue also reproduces in 54.0.2840.99, so it may not be a regression. The issue seems to happen more often in Chrome 55, and in our production code we only see this problem in Chrome 55. However, this may boil down to a race condition that was exposed due to unrelated changes in Chrome 55.
Labels: M-54
Labels: Needs-Triage-M54
Cc: kkaluri@chromium.org
Labels: Needs-Feedback
Unable to reproduce this issue on windows 10 with chrome version M55-55.0.2883.59
These are the steps i followed
1. Opened the chrome and loaded the given extension.
2. Opened the w3.org site and then developer tools
3. from chrome://extensions open background page for the loaded extension.
4. In the w3.org  site, clicked multiple times on the links on the left side

Observed the both consoles are updating simultaneously.

Please look into the attached screen-cast and let us know if any steps are missed in the issue reproduction

Thank You...  
Issue 667787.mp4
3.8 MB View Download
It may be necessary to reproduce the behavior on a slower machine as this looks like a timing issue. In the attached video, notice that one of the clicks successfully reports the round-trip message when navigating to a new page.

The issue does not reproduce for clicks that remain on the same page. I reproduce the issue by clicking back and forth between pages.

Beyond that, it's not obvious to me what is different between the machines where the issue reproduces and where it does not. I would be happy to gather further debugging information if you have suggestions.
667787-demonstration.mp4
1.9 MB View Download

Comment 6 by woxxom@gmail.com, Dec 10 2016

It might be working as expected since the messaging is asynchronous:

1. click initiates navigation to another page
2. message from content script is queued
3. background page receives the message
4. message from background page is queued
5. meanwhile the browser does a lot of stuff (checks the cache, parses the new page) so by the time it decides to process the queued message from the background page the previous page context is already destroyed along with its onMessage listener.

P.S. I'm not a chromium developer.
Project Member

Comment 7 by sheriffbot@chromium.org, Dec 19 2016

Labels: -Needs-Feedback Needs-Review
Owner: kkaluri@chromium.org
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
kkaluri@, do we have a repro of this issue yet? Any thoughts on how the reporter can help gather more data, if needed, to debug this regression (not clear if this is a regression or not, though).

Comment 9 by dk...@chromium.org, Feb 6 2017

Components: Platform>Extensions
Labels: -Hotlist-Interop
Removing hotlist interop since this seems to be an extensions issue.
Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 
Labels: -Needs-Review
Project Member

Comment 12 by sheriffbot@chromium.org, Mar 15 2018

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, 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

Sign in to add a comment