Tested this issue on Mac OS 10.11.6 & Windows-7 using chrome latest stable M52-52.0.2743.82 by following steps mentioned below.

1. Installed the attached Chrome polluted-extension
2. Opened the attached id_global HTML file 
3. Pressed Ctrl+Shift+I
4. Observed no text in the console.
 
jamie@ - Could you please upgrade your chrome to latest stable and recheck for this issue. In case if it still persists please provide a snapshot or screen-cast of the actual behavior for better understanding.

Thanks!

I think that it doesn't work when loading file:// URLs. I am on macOS using latest Chrome. I placed the included HTML file in a Pow project folder under public/ so that it would be served as a static HTML file and then navigated to http://testsite.dev/id_global.html to see the result. I'm attaching relevant screenshots.

Deleted: screenshots.zip 520 KB

screenshots.zip 520 KB Download

Tested the same on Mac OS using chrome latest stable. Still no luck, I am unable to see any console errors as shown in the provided screen-shot. Placed the id_global.html file in to polluted-extension folder and tried navigating to the link directly but still failed to repro it.

jamie@- Will you mind providing a screen-cast from your end for better understanding? You can record a screen-cast from below link.
https://screencast-o-matic.com/home

I will make a screencast as soon as my schedule allows, but I'm curious about this bit: "Placed the id_global.html file in to polluted-extension folder and tried navigating to the link directly but still failed to repro it."

The screenshot shows that I'm accessing this file from a real web server, and I'm not sure how placing the HTML file inside the extension folder would help. If you're accessing it over file:// I'm fairly sure that it will not work. Did you confirm that the script is showing up in the content scripts for the page?

This is actually intended behavior, thanks to Microsoft back in the day.  See these links:

http://www.2ality.com/2012/08/ids-are-global.html
http://stackoverflow.com/questions/6381425/is-there-a-spec-that-the-id-of-elements-should-be-made-global-variable
Fixed link to Whatwg thread from previous link: https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Apr/0000.html

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

jamie@ - Any update on this bug? As you mentioned in comment #5 could you please provide a screen-cast for this issue?And could you please take a look on comment #7 as David mentioned saying it's intended on Windows. Is this is the same case with Mac?

While I understand this is intended behavior within the page, what shouldn't be allowed is for those global variables to pollute my content script and define variables I don't expect to be defined in Chrome.

I'm honestly not sure what this screencast shows that isn't already in the screenshots I provided earlier.  My instinct says that the example page that causes the pollution isn't properly being loaded such that the content scripts are injected into the page, which is why I asked, "Did you confirm that the script is showing up in the content scripts for the page?" at the end of comment #5.

Deleted: id_global_pollution.mov 1.9 MB

id_global_pollution.mov 1.9 MB Download

From Chrome-TE team we have no clue how to repro this issue, As per comment #5 and #12 it's sure this is intended behavior and not able to repro locally. So adding TE-NeedsTriageHelp label and requesting someone from Dev team to look in to it for further updates.

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

I guess this one could be confirmed now that Tavis has found a way to exploit it? https://bugs.chromium.org/p/project-zero/issues/detail?id=1225&desc=6

Sorry for the delay.  Just to clarify, this is intended behavior in all browsers environments and on all operating systems.  It's one of those quirks that a browser vendor (Microsoft) implemented back in the day that's been kept around for backwards compatibility with older websites that may depend on this behavior.

You can easily reproduce this in the Developer Console:

// First check that the global doesn't yet exist.
console.log(typeof foobar); // 'undefined'

// Create a DOM Element, and give it the id 'foobar'.
var elt = document.createElement('div');
elt.id = 'foobar';
document.body.appendChild(elt);

// Verify that the foobar variable now exists and points to the DOM Element
console.log(typeof foobar); // 'object'
console.log(foobar instanceof Element);  // true

Yes, I understand that the behavior should work for the website. But my contention is that this global should not cross over the isolated world boundary into the extension. If the decision is that this is indeed allowed, then that is fine, but I wanted to make sure my objection to the behavior as it is now was clear and fully understood.

Reporter, DOM is the same for both content script and the web page script so the observed behavior is correct. Only JS-related stuff is isolated for the content script.

This is a duplicate of  issue 777545 .

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

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