Using the per-revision bisect providing the bisect results,

Good build: 55.0.2861.0 (Revision: 418732).
Bad build: 55.0.2862.0 (Revision: 419063).
You are probably looking for a change made after 418834 (known good), but no later than 418835 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might
 get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/e7ac1bbe93e087b173d503ca13b1e3b6f703b785..aaf5ece46ff3b24c2f5ff0054600900f60c70ce4

From the CL above, assigning the issue to the concern owner

hiroshige@ Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2275493002

Thanks..

rkote@,
Could you please check the issue on latest Canary#58.0.3018.0 since we are unable to reproduce the issue on latest canary & update the thread accordingly.

Thank you!!

Friendly ping!!
hiroshige@,
Still we are able to reproduce the issue on Windows 7 using chrome stable-56.0.2924.87 .Could you please look into this and update the thread accordingly.
Thanks!!

Hmm, this looks quite flaky. Bisecting again...

During M-56, 57 and 58, this issue became less likely. I observed bad behavior on r446811 on Linux, and currently no bad behavior on or after r446812, but r446812 looks unrelated. Probably this still occurs after r446812, with low probability.

Still able to reproduce the issue on Win-10 using latest canary #59.0.3046.0.

hiroshige@ - Friendly Ping...!!

Could you please provide any update on this issue.

Thanks...!!

Hmm.

On normal load (i.e. when clicking the extension's icon), mainapp.html is opened once and its load event is triggered once, and thus background script (main.js)'s __onExtWindowLoad() is called once.

On reload (as described above), mainapp.html is opened twice and its load event is triggered twice (once for each mainapp.html).

If the things are executed in the order:
- The first mainapp.html's load event
- background page's console log: "Loaded storage"
- The second mainapp.html's load event
then the extension works as expected.

If the things are executed in the order:
- background page's console log: "Loaded storage"
- The first mainapp.html's load event
- The second mainapp.html's load event
then the extension does not work (loading forever).

Perhaps, pressing "Reload" button causes
1. reloading of already opened mainapp.html (which does not occur when clicking the extension icon), and
2. reloading of the background page, which eventually triggers opening a new mainapp.html via background script.

This issue is exposed due to the race between the first mainapp.html's load event and the processing of background script and because I moved the load event a little later, but I expect the "reload" button behavior is the root cause.

Extension people, what do you think?

I suspect the following occurs:

When we follow the reported steps,
(2a) Open Hangout Extension's window ("mainapp.html?uv_main_window", let this Window X),
(2b) Kill the Extension's process (Window X becomes "Aw, Snap!"), and
(3) Click the reload button of Window X.

Then, the following occur:
(4a-1) Window X is reloaded.
(4a-2) Window X's window.onload() is called and thus background script (main.js)'s __onExtWindowLoad() is called.

(4b-1) In the mean time, background script (main.js) is also reloaded.
(4b-2) Zk[b] is initialized in main.js.
(4b-3) The background script opens a new window ("mainapp.html?uv_main_window", let this Window Y).
(4b-4) Window Y's window.onload() is called, and thus background script (main.js)'s __onExtWindowLoad() is called again.

If (4a-2) occurs before (4b-2), then (4a-2) causes Window X to close, and (4b-4) works correctly (expected bebavior).

If (4a-2) occurs after (4b-2), then Window X remains (but showing loading animation forever), and (4b-4) causes Window Y to close.