Determine the nuances of aliasing `chrome` and `browser`

[patrick kettner]

Now that #508 has been merged (🎉), our team began discussing the specifics on how to alias chrome to browser. It turns out, what we want to do is different from everyone, but also everyone is different from everyone.

In Firefox, chrome and browser appear to be clones of the same object. So the values are the same, but updating one does not change another.

browser.foo = 123
console.log(browser.foo)
123
console.log(chrome.foo)
undefined

In Safari, chrome and browser appear to be a direct alias to one another

browser.foo = 123
console.log(browser.foo)
123
console.log(chrome.foo)
123

What Chrome wants to do is make chrome and browser separate objects, but make the various properties of each object a direct alias.

So in the above example, the Firefox behavior would be matched

browser.foo = 123
console.log(browser.foo)
123
console.log(chrome.foo)
undefined

But modifying a specific property or value inside of chrome or browser would update the other.

browser.runtime.PlatformArch.ARM = 123
console.log(browser.runtime.PlatformArch.ARM)
123
console.log(chrome.runtime.PlatformArch.ARM)
123

The reason why we like this option is the mix of ease of implementation from aliasing, while also allowing us to sluff off APIs we do not want to carry forward into browser.

[Timothy Hatcher]

I see the benefit of having separate namespace objects for each, while sharing everything else internally. However, that would be technically tricky for Safari/WebKit to support. In practice, we don't anticipate the need to have them be separate for us, so we will likely keep our implantation as-is (direct aliases of one another, described above).

@patrickkettner What APIs do you plan to "sluff off" of browser?

[tophf]

to sluff off APIs we do not want to carry forward into browser.

This implies browser is the successor of chrome and not an alias, which doesn't seem conceptually justified. Edit: although removing junk like csi and loadTimes would indeed make sense as the next comment says.

[Jackie(Guokai) Han]

The reason why we like this option is the mix of ease of implementation from aliasing, while also allowing us to sluff off APIs we do not want to carry forward into browser.

chrome has some non-extension properties, like chrome.loadTimes. This approach allows Chrome to keep chrome for some private APIs, and browser only contains extension-related APIs. IMO, from a practical perspective, whether chrome === browser should not have much impact on developers.

[patrick kettner]

@xeenon
> What APIs do you plan to "sluff off" of browser?
I don't have a definitive list, but I would imagine things like loadTimes or csi, that are not Chrome specific (thanks @hanguokai!).

[patrick kettner]

During the call outlined in #537, I believe that the following was agreed on

• chrome.* needs to continue to exists for backcompat with existing extensions in all browsers
• There should be consistency between browsers with how chrome and browser are aliased
• deep changes to one, should reflect on the other (e.g. chrome.runtime.foo = "bar" should result in browser.runtime.foo also being "bar"
• 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)

@oliverdunk @zombie @xeenon @Rob--W is the above true?

[Timothy Hatcher]

Sounds good.

[Oliver Dunk]

Sounds good to me.