fix: Prevent a webpage document element to be detected as the Extension API object

[rpl]

This PR applies some changes to the webpage used by the integration test suite, to reproduce the same issue that is described in this comment on issue #68 and on https://crbug.com/865881

And the additional check browser instanceof window.Node in the polyfill sources, to detect this scenario and prevent the DOM node to be detected as an existing Extension API object (and turn the polyfill into a no-op as when it runs on Firefox where the browser API object is natively available).

[Rob--W]

Add another <div id="browser"></div> to demonstrate the issue that I mentioned above.

[rpl]

@tophf have you deleted Rob comment by mistake?

Follows @Rob--W deleted comment for reference

---

In src/browser-polyfill.js:

> @@ -6,7 +6,7 @@
  * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
 "use strict";
 
-if (typeof browser === "undefined") {
+if (typeof browser === "undefined" || browser instanceof window.Node) {

Change to:

if (typeof browser !== "object" || browser && Object.getPrototypeOf(browser) !== Object.prototype) {`

or (if you prefer shorter code or don't want to rely on Object.getPrototypeOf):

if (typeof browser === "undefined" || browser && browser.__proto__ !== Object.prototype) {

or (if you don't want to rely on Object):

if (typeof browser === "undefined" || browser && browser.__proto__ !== ({}).__proto__) {

Why? Well:

• Using instanceof window.Node won't rule out tampering. You'll see that in this case, x is a HTMLCollection: data:text/html,<a id=x href>a</a><a id=x href>b</a><script>console.log(x)</script>
• If someone has happened to define a primitive value as "browser", then we still want to overwrite it. (this is an accidental side-effect of my chosen implementation)

See also https://www.w3.org/TR/html5/browsers.html#named-access-on-the-window-object

[tophf]

@tophf have you deleted Rob comment by mistake?

I don't have any rights in this repo so I couldn't have deleted anyone else's comments directly. I guess github created a "thread" for my comment and Rob commented in that thread. Then I realized my comment is wrong and deleted it, which made github delete the entire "thread".

[Rob--W]

LGTM.

Do we already have an integration test that verifies that the polyfill does not overwrite the browser global in Firefox (content scripts and extension/background page)?

[rpl]

Do we already have an integration test that verifies that the polyfill does not overwrite the browser global in Firefox (content scripts and extension/background page)?

@Rob--W

We have a unit test (which simulates the behaviors in an extension page/background page):

webextension-polyfill/test/test-browser-global.js

Lines 15 to 27 in 450eee5

	it("does not override the global browser namespace if it already exists", () => {
	const fakeChrome = {
	runtime: {lastError: null},
	};
	const fakeBrowser = {
	mycustomns: {mybrowserkey: true},
	};
	return setupTestDOMWindow(fakeChrome, fakeBrowser).then(window => {
	deepEqual(window.browser, fakeBrowser,
	"The existing browser has not been wrapped");
	});
	});

And an integration test which tests the behavior in a content script context on Chrome and Firefox:

webextension-polyfill/test/fixtures/detect-browser-api-object-in-content-script/content.js

Lines 1 to 18 in 450eee5

	test("browser api object in content script", (t) => {
	t.ok(browser && browser.runtime, "a global browser API object should be defined");
	t.ok(chrome && chrome.runtime, "a global chrome API object should be defined");
	if (navigator.userAgent.includes("Firefox/")) {
	// Check that the polyfill didn't create a polyfill wrapped browser API object on Firefox.
	t.equal(browser.runtime, chrome.runtime, "browser.runtime and chrome.runtime should be equal on Firefox");
	// On Firefox, window is not the global object for content scripts, and so we expect window.browser to not
	// be defined.
	t.equal(window.browser, undefined, "window.browser is expected to be undefined on Firefox");
	} else {
	// Check that the polyfill has created a wrapped API namespace as expected.
	t.notEqual(browser.runtime, chrome.runtime, "browser.runtime and chrome.runtime should not be equal");
	// On chrome, window is the global object and so the polyfilled browser API should
	// be also equal to window.browser.
	t.equal(browser, window.browser, "browser and window.browser should be the same object");
	}
	});

[Rob--W]

And an integration test which tests the behavior in a content script context on Chrome and Firefox:

webextension-polyfill/test/fixtures/detect-browser-api-object-in-content-script/content.js

Lines 1 to 18 in 450eee5

	test("browser api object in content script", (t) => {
	t.ok(browser && browser.runtime, "a global browser API object should be defined");
	t.ok(chrome && chrome.runtime, "a global chrome API object should be defined");
	if (navigator.userAgent.includes("Firefox/")) {
	// Check that the polyfill didn't create a polyfill wrapped browser API object on Firefox.
	t.equal(browser.runtime, chrome.runtime, "browser.runtime and chrome.runtime should be equal on Firefox");
	// On Firefox, window is not the global object for content scripts, and so we expect window.browser to not
	// be defined.
	t.equal(window.browser, undefined, "window.browser is expected to be undefined on Firefox");
	} else {
	// Check that the polyfill has created a wrapped API namespace as expected.
	t.notEqual(browser.runtime, chrome.runtime, "browser.runtime and chrome.runtime should not be equal");
	// On chrome, window is the global object and so the polyfilled browser API should
	// be also equal to window.browser.
	t.equal(browser, window.browser, "browser and window.browser should be the same object");
	}
	});

The way that we inject APIs in Firefox are different for extension pages and content scripts, so a test for the background page seems desired.

browser being identical to chrome in a content script seems to be a small bug to me, because it adds promise APIs to the chrome namespace in content scripts: https://bugzilla.mozilla.org/show_bug.cgi?id=1296896
In extension pages, chrome and browser are already different. We just need to make sure that the polyfill does not replace the browser in this case.

[Rob--W]

LGTM with very minor nits.

[Rob--W]

Why return false;? If you don't want the handler to respond, jus return void (return;).
Or make this a non-async function and call sendResponse({ ... }); in the end.

[Rob--W]

Add a comment that in browsers without a browser API, this will point to the <div id="browser"> in the page.

[Rob--W]

Let's check window.browser too?