New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 657804 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression

Blocking:
issue 624697



Sign in to add a comment

Regression:Delay is seen while loading the "the-weather-by-weather24.com" extension

Reported by adha...@etouch.net, Oct 20 2016

Issue description

Chrome Version:55.0.2883.21 Revision b9eabca6f064bcaa5aa645e4b3eaba90cf47a43c-refs/branch-heads/2883@{#201}(32/64 bit)
OS:Windows (7,8,8.1,10),Linux (14.04 LTS)

TEST URL:https://chrome.google.com/webstore/detail/the-weather-by-weather24c/nghgfpdgefkcdljgapbnmdgdjmfhhcmj

What steps will reproduce the problem?
(1)Launch chrome,navigate to the above URL and click on add to chrome.
(2)Click on extension icon in Extensions overlay.
(3)Observe.

Actual:Delay is seen while loading the extension.(kindly refer the video)

Expected:Extension should load properly without any delay.

This is a Regression issue broken in M-55,will soon update other info.

Note:Above issue is not seen on Mac OS.
 
Actual result.mp4
1.2 MB View Download
Expected result.mp4
328 KB View Download
stik isling ploym go 1.000
Cc: kkaluri@chromium.org
Labels: hasbisect-per-revision
Owner: hirosh...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on both Windows 10 and ubuntu 14.04  on latest chrome beta version 55.0.2883.21. 
Issue is broken in M55. 

Below are the bisect details for the same:

Bisect Info:
===========
Good Build : 55.0.2861.0,  Revision Range (418732)                                           
Bad Build  : 55.0.2862.0 , Revision Range (419063)


After executing the bisect script in reverse, i got the following CL's between good and bad build versions
=============================================================================================== 
https://chromium.googlesource.com/chromium/src/+log/e7ac1bbe93e087b173d503ca13b1e3b6f703b785..aaf5ece46ff3b24c2f5ff0054600900f60c70ce4


The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/aaf5ece46ff3b24c2f5ff0054600900f60c70ce4

From the above CL suspecting the below change
Review URL:  https://codereview.chromium.org/2275493002


hiroshige@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Thanks.!

Cc: brajkumar@chromium.org
hiroshige@ Issue is still repro on chrome latest Dev #56.0.2900.0. Since this issue is marked as P1 can we get any update on this bug if it's related to your change.

Thanks!
Components: Blink>Loader
Status: Started (was: Assigned)
I confirmed the first bad revision is my https://codereview.chromium.org/2275493002 as commented in #2, locally reproduced on Linux (a little flaky though).

I think this is an issue of the "the-weather-by-weather24.com" extension (and this crbug should be closed as WontFix), because the extension seems to have a race between setTimeout() and <body>'s onload event:

chrome-extension://nghgfpdgefkcdljgapbnmdgdjmfhhcmj/popup.html
loads popup_outro.js at the end of its <body>, and
popup_outro.js calls init() defined in popup.js,
which schedules <iframe> creation in load_it() in 10 msec.

If load_it() is called after <body>'s onload handler, then it works fine (=Expected Case).

However, if load_it() is called before <body>'s onload, then the new <iframe> start blocking <body>'s onload and thus the popup window does not appear until the <iframe> is completely loaded, which takes several seconds (=Actual case).

There is nothing that guarantees <body>'s onload handler is called within 10 msec from popup_outro.js's execution, and my CL modified the timing of <body>'s onload handler slightly, thus just exposed the race condition.
Probably the extension should schedule (or call) load_it() in <body>'s onload, rather than just before <body>'s end.
Blocking: 624697
Status: WontFix (was: Started)
Closing as WontFix as described in Comment #4.
Please report the issue to the developer of the extension.

Sign in to add a comment