update window.browser spec per #532

[patrickkettner]

Fixes #532

[oliverdunk]

Thanks Patrick! I left a review with some wording suggestions. I know there was some concern in the last meeting about if it made sense to do this (and I'm still not fully sure) so I think we should get approval from @Rob--W and others before deciding if we merge.

[patrickkettner]

@oliverdunk thanks for the review! I believe I addressed everything in the last update, so another look at some point would be appreciated!

@Rob--W I'd love any feedback you have

[Rob--W]

Besides the review, another thought related to your comment at #532 (comment)

Whether or not chrome.foo = "bar" would automatically make browser.foo === "bar" is left up to the user agent to decide. (With our proposal, this would be false. My understanding was that Firefox was fine with changing to match behavior, but Safari was not interested in changing their strict aliasing as they didn't have anything on chrome they didn't also want on browser)

The thought occurred to be that there may be little point in distinguishing the browser and chrome namespaces. Any existing property of chrome is de facto reserved, because if another browser were to introduce a new API under browser.loadTimes, for example, then developers would be surprised when they use chrome.loadTimes with the expectation of browser.loadTimes pointing to the same object. browser as a namespace explicitly permits UA-specific additions, which is good enough to allow Chrome to expose chrome.csi as browser.csi, but as a browser-specific "extension" API. Thoughts on this one?

Sorry, I was under the impression I was just approving the typo commit, not this whole PR.

I need to find some time still to comment on this as a whole.

[patrickkettner]

The thought occurred to be that there may be little point in distinguishing the browser and chrome namespaces

@Rob--W My thought process was that a developer may be surprised to see that modifying browser.foo has different effect to chrome.foo in different browsers. Since testing showed that to be true, it makes sense to attempt to standardize behavior to remove that surprise. Since we all have unique behavior (if you count our plan as a behavior), there would be some kind of change somewhere for that behavior to be consistent.
If no one plans on changing their behavior, then I agree that there is no point in specing out the behavior, since it is just saying "anyone can do whatever they want". But if we want to align on expectations, then it makes sense to me to write down what those expectations are.

[Rob--W]

Since Chrome is unwilling to have chrome === browser that Safari and Firefox already supports, we will spec the "not direct alias" behavior.

[Rob--W]

Suggested change

	// As `chrome` and `browser` are not direct aliases,
	// modifying one top level values will not change the other
	// When `chrome` and `browser` are not direct aliases,
	// modifying one top level values will not change the other:

Rephrased to avoid the impression that chrome and browser couldn't be direct aliases.

[Rob--W]

Suggested change

	console.log(globalThis.chrome.FAKE); //undefined
	console.log(globalThis.chrome.FAKE);
	// ^ undefined when chrome and browser are not direct aliases.
	// ^ may be true if browser === chrome.