ilyaigpetrov@Thanks for the issue.

Tested the issue on windows 7 using chrome version 58.0.3029.110 with the steps from comment #0.
Could you please find the attached screen cast and confirm if anything missed here.
After reloading the page the the browserAction icon should display as "I'm the Non default pop up".Is this the expected behaviour.
Please confirm to triage the issue further.

Thanks,

Deleted: 727023.mp4 1.6 MB

	727023.mp4 1.6 MB View Download

Hi, kavvaru@.

> After reloading the page the the browserAction icon should display as "I'm the Non default pop up". Is this the expected behaviour.

After reloading popup MUST contain message "Welcome to the TEST!" -- it is the non-default popup. This message is also seen before reload.

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.5 with chrome Stable #59.0.3071.86, Canary #61.0.3123.0 and also in earlier version M45-#45.0.2454.101, hence marking it as untriaged.

These are the steps followed.

1. Install extension.
2. On chrome://extensions open background page of the extension.
3. Open http://no-such-page-foo.com (as a page that produces error).
4. Click browserAction icon and Observed the "Welcome to the TEST" pop up
5. Hit F5 or reload page by other way.
6. Click browserAction icon and observed the default popup.

Attaching the screen-cast for reference.

Note:
-----
Builds are less than M45 are crashing while launching chrome.

Deleted: 727023.mp4 583 KB

	727023.mp4 583 KB View Download

Assigning to Devlin for browserAction interaction.

I finally had a moment to sit down and take a look at this.  The TL;DR is that I don't think there's really a bug here, but there is some non-determinism.

What's happening is that the webRequest onErrorOccurred event can fire either before or after the tab finishes its navigation (since it happens as the network requests are being made, rather than being based on the outcome of a navigation).  We also clear tab-specific values for page and browser actions when the tab navigates.  What this means is that the two following flows are possible:

- clear tab-specific values for action popups
- receive webRequest.onErrorOccurred, call browserAction.setPopup

or the inverse:

- receive webRequest.onErrorOccurred, call browserAction.setPopup
- clear tab-specific values for action popups

It appears that, funnily enough, whether the commit is a reload or a fresh navigation can influence the ordering here (since there are no guarantees).

I don't think we want to spec out the relationship between a webRequest error in the main frame being dispatched and when we clear the tab values for a specific tab, and I don't think there should be any strong guarantees between the two APIs.  If we *were* to change something, we could hypothetically clear the values for the tab when navigation begins, but that can fail in certain cases as well (like a navigation abort).

I think for this use case, the right thing to do is to use the webNavigation API, which is a little more deterministic with respect to tabs (and, as the reporter pointed out, works properly in this case).  webRequest monitors network requests, but is somewhat independent from tab loading.