Your code is incorrect: chrome.runtime.onMessage listener should "return true;" in order to be able to respond to the sender when the asynchronous chrome.tabs.executeScript completes.

I've attached a fixed extension that correctly returns the result.

Updated the fixed version: now if an error has occurred it's displayed in the popup.

Deleted: activetab-fixed.zip 1.3 KB

activetab-fixed.zip 1.3 KB Download

I've incorporated the changes from Comment 2 into the repository for this testcase on GitHub: https://github.com/testcases/browser-extension-testcases/tree/master/activetab

Note that these changes are only to make the testcase *easier to follow* (you can skip step 2 in the reproduction steps, and the error in the observed behavior will be displayed in the extension's UI rather than the console). It does *not* affect the presence of this bug, which is still valid.

The fixed extension in comment#2 and the new testcase from comment#3 both work successfully (text from the webpage is displayed after injection, no errors are displayed in the background page console) as observed in 56.0.2924.87 (r433059), 58.0.3020.0 (r451874), and some previous versions of Chrome I tried.

Make sure the active page is a normal web page, not a built-in one like chrome:// or chrome-extension:// - Do note, the default new tab page is actually chrome://newtab/ so you can't execute scripts directly, you'll have to inject in the sub-frame that has https://www.google.***/_/chrome/newtab URL, see examples on stackoverflow.com

Actually, the initial version in the bug report doesn't display the permission error on normal web pages. It just didn't send the results back because "return true" was missing.

Uh, the error *definitely was* being presented on normal web pages - that's *where I copied the message from*. (Not that it matters, but the specific page I tested against, just because I had it open, was https://jasonsavard.com/forum/discussion/2218/error-with-grab-the-entire-page .)

Strangely, returning `true` from the addMessage listener *does*, in fact, make this bug go away, even if you never have to use the `respond` function (as is the case in the use case where I discovered this bug), so then the parameters of this bug are a little different: it's not simply "activeTab permission in extensions does not extend to background page", but "activeTab permission in extensions only extends to background page *as long as the message channel is open*".

See the original test case.

Okay, this is starting to turn into a weird sort of reverse-Heisenbug.

I just rewrote the test case to return the result of the script injection via a new `chrome.runtime.sendMessage` invocation instead of the `response` callback (see attachment), which should close the connection and exhibit the bug behavior that I'm seeing. And, indeed, if you *insert a breakpoint* into the script (at line 8 of popup.js), you see the error being returned, as I described. The button will turn red and display the aforementioned error message.

However, if you *don't* insert a breakpoint in the debugger when the message is dispatched, then it *will* execute successfully, and the button will be *green*, with the page contents.

Perhaps the problem is just that the activeTab permission is simply revoked too quickly after interaction (and the breakpoint causes the stages to span that time gap)? In my use case, the code that causes the activeTab permission to break takes a fair amount of time to execute.

Experimenting on this now...

Deleted: testcase-heisenbuggy.zip 1.6 KB

testcase-heisenbuggy.zip 1.6 KB Download

Okay, at this point, I'm pretty sure that it is, in fact, *opening the debugger on the background page* that triggers this issue - when I filed this bug, I was trying to debug what I later figured out, by setting "<all_urls>" as the permission, was an unrelated issue. I've tried lots of different permutations of this test case *without* opening the debugger, and they've all succeeded; the one consistent thread through every *failure* I've observed has been *the presence of the debugger itself*.

So, yeah; still a valid bug, just not the bug I thought it was. At this point, I'm pretty sure the best consistent repro steps are the ones I described in comment #7: debug the popup with a breakpoint on line 8 and watch the injection fail.

And, as such, the correct formulation of the issue title would be "debugging / inspecting extension scripts breaks activeTab permission".

Tested in chrome # 56.0.2924.87  and Canary #58.0.3025.0 on win 10.0 & 7 and Please find the screen shots for your reference.

@ stuart: Could you please let me know if i have missed anything and if possible, provide us with a expected behaviour of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: 695340.mp4 1.1 MB

	695340.mp4 1.1 MB View Download

@rbasuvula: You didn't open the popup for inspection in the debugger. See comments 7 through 9 - it is the *presence of the debugger being open* that triggers this issue.

Steps to reproduce: after clicking the browser action button and opening the popup (0:04 in the video), *right click within the popup and click "Inspect" on the context menu* before clicking the "Inject script" button in the popup (0:05 in the video). Inspecting the popup causes the script injection to fail.

Tested the issue on chrome Stable #56.0.2924.87, Canary 58.0.3026.0 in Windows 10.0 and was able to reproduce the issue.Unable to inject the script. 

This is a Non-Regression issue since seeing this from M35 #35.0.1898.0, Making the status to Untriaged so that the issue would get addressed.

Note : Able to reproduce the issue in MAC 10.12 and Linux Ubuntu 14.04.

Thank you.

I can confirm that this issue still exists. We need this functionality in order to re-insert content scripts after the extension has been updated.