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.

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

update window.browser spec per #532 #546

Merged
merged 7 commits into from
Nov 7, 2024

Conversation

patrickkettner
Copy link
Contributor

Fixes #532

Copy link
Member

@oliverdunk oliverdunk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
@patrickkettner
Copy link
Contributor Author

@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

Copy link
Member

@Rob--W Rob--W left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
Co-authored-by: Rob Wu <rob@robwu.nl>
xeenon
xeenon previously approved these changes Feb 27, 2024
@xeenon xeenon dismissed their stale review February 28, 2024 02:11

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 and others added 2 commits March 7, 2024 09:36
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
@patrickkettner
Copy link
Contributor Author

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.

Copy link
Member

@Rob--W Rob--W left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

specification/window.browser.bs Outdated Show resolved Hide resolved
specification/window.browser.bs Outdated Show resolved Hide resolved
patrickkettner and others added 2 commits November 7, 2024 08:12
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
Copy link
Member

@Rob--W Rob--W left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xeenon Does this look good to you too?

@xeenon xeenon merged commit e62ab22 into w3c:main Nov 7, 2024
1 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Determine the nuances of aliasing chrome and browser
4 participants