Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Determine the nuances of aliasing chrome and browser #532

Open
patrickkettner opened this issue Jan 30, 2024 · 7 comments · May be fixed by #546
Open

Determine the nuances of aliasing chrome and browser #532

patrickkettner opened this issue Jan 30, 2024 · 7 comments · May be fixed by #546
Labels
discussion Needs further discussion inconsistency Inconsistent behavior across browsers

Comments

@patrickkettner
Copy link
Contributor

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.
@xeenon xeenon added inconsistency Inconsistent behavior across browsers discussion Needs further discussion and removed needs-triage labels Jan 30, 2024
@xeenon
Copy link
Collaborator

xeenon commented Jan 31, 2024

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
Copy link

tophf commented Feb 1, 2024 •
edited
Loading

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.

@hanguokai
Copy link
Member

Screenshot 2024-02-01 at 17 10 00

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.

@patrickkettner
Copy link
Contributor Author

@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!).

@Rob--W Rob--W mentioned this issue Feb 1, 2024
Merged
@patrickkettner
Copy link
Contributor Author

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?

@xeenon
Copy link
Collaborator

xeenon commented Feb 2, 2024

Sounds good.

@oliverdunk
Copy link
Member

Sounds good to me.

patrickkettner added a commit to patrickkettner/webextensions that referenced this issue Feb 14, 2024
@patrickkettner
update window.browser spec per w3c#532
b25688b
@patrickkettner patrickkettner linked a pull request Feb 14, 2024 that will close this issue
Open
@Rob--W Rob--W mentioned this issue Aug 1, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discussion Needs further discussion inconsistency Inconsistent behavior across browsers
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

update window.browser spec per #532 patrickkettner/webextensions
5 participants
@xeenon @patrickkettner @hanguokai @tophf @oliverdunk