enazarev@ Thanks for the issue.

Able to reproduce this issue on Windows 10, Mac OS 10.13.5 and Ubuntu 14.04 on the reported version 69.0.3452.0 and the latest Canary 69.0.3460 by following the steps given above.
Attached is the screen shot for reference.

This is a Non-Regression issue as this behavior is observed from M-60 chrome builds.

Hence marking this as Untriaged for further updates from Dev.

Thanks..

Deleted: 852955-M60.PNG 69.6 KB

	852955-M60.PNG 69.6 KB View Download

Unfortunately, we probably won't be able to dig into a 980 KB extension to figure out exactly what's causing this in the near future.  If you can reduce the test case down a little more, that would be very helpful in diagnosing.

Marking as available for now, but if we can more easily isolate what's going on, we might be able to better triage.

> But firing API event is so basic it must work robust. And any other code shouldn't influence for this behaviour.

This isn't really true - there's plenty that extension code could do to prevent this event from firing.  For instance, removing the event listener, closing the tab before it's complete, blocking the load, etc.

Here is a minimal test case and new steps to reproduce
0. Open some valid page
1. Load app_min as an extension
2. Open app_min background console
3. Reload page opened on `0` step. Confirm there are three line containing 
"
Status: loading; (background)
Status: undefined; (background)
Status: complete; (background)
"
4. Open newtab. (Should be replaced by empty white page)
5. Go to any valid location OR
   (just close this tab AND reload any previously opened page)
6. Confirm there is no any new lines in console

Deleted: app_min.zip 8.8 KB

app_min.zip 8.8 KB Download

And if open newtab then listener in background script start working again.

Thanks for the minified case!

dbertoni@, can you look into this?

@enazarev:

Trying to reproduce this, I see the following:

Steps 0-3: Load chrome.google.com. Nothing different from your description. The console contains:

Status: loading; (background)     tabListener.js:6
Status: undefined; (background)   tabListener.js:6
Status: complete; (background)    tabListener.js:6

Step 4: Open new tab. 3 new lines are added to the console output. The console contains:

Status: loading; (background)     tabListener.js:6
Status: undefined; (background)   tabListener.js:6
Status: complete; (background)    tabListener.js:6
Status: loading; (background)     tabListener.js:6
Status: undefined; (background)   tabListener.js:6
Status: complete; (background)    tabListener.js:6

Step 5: Close new tab. Reloaded chrome.google.com. 3 new lines are added to the console output. The console contains:

Status: loading; (background)     tabListener.js:6
Status: undefined; (background)   tabListener.js:6
Status: complete; (background)    tabListener.js:6
Status: loading; (background)     tabListener.js:6
Status: undefined; (background)   tabListener.js:6
Status: complete; (background)    tabListener.js:6
Status: loading; (background)     tabListener.js:6
Status: undefined; (background)   tabListener.js:6
Status: complete; (background)    tabListener.js:6

So I'm not sure if I'm reproducing the bug or not. I think I'm not, but can you please verify? Note that this is with a local build of Chromium on source code that's almost a month old (origin is at 3bc094ac7bb973831473bed81692414ee042f1e8).

I will try to reproduce this with M67 as well.

@dbertoni

Thank you for response

No, you didn't. After you close new tab (step 5) and reloaded chrome.google.com there shouldn't appear new lines.

I have updated GC and it still reproduced

Google Chrome	69.0.3472.3 (Официальная сборка) dev (64 бит) (cohort: Dev)
Версия	b978b9c8052fb79ad76080d8b6e7539e4e797693-refs/branch-heads/3472@{#5}
ОС	Windows
JavaScript	V8 6.9.207

We have not been able to reproduce this on any client (Windows, Mac or Linux).

Is it possible you have another extension installed that's interfering with the API? Have you tested on a clean install of Chrome with no other extensions?

Yes, I have tested on another profile (--user-data-dir) and it wont reproduce for me too.

But when I testing on my regular profile I switch off all other extensions except simplified example.

I managed to repro this locally, but I'd like the original reporter to try something.

Run chrome with the following command line arguments:
1. --enable-features=NativeCrxBindings
2. --disable-features=NativeCrxBindings

If 1 repros and 2 doesn't, this might be the same root cause as  crbug.com/850654 

Thank you @amistry for suggestion

Yep. It behaves like as you say. It do reproduce with enable flag and don't with disable.

Oh! Forgot to mention. I have updated since the topic started.
Now I'm on version  69.0.3497.12, dev 64

And my prev comment is related to this version

Can you try dev/canary 70.0.3523.0 or later. It should be fixed.

@amistry, thank you.  Seems it is fixed :)