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

navigationType in apply the history step used without a null check #10086

Open
ADKaster opened this issue Jan 25, 2024 · 1 comment
Open

navigationType in apply the history step used without a null check #10086

ADKaster opened this issue Jan 25, 2024 · 1 comment
Labels
clarification Standard could be clearer topic: navigation

Comments

@ADKaster
Copy link
Contributor

What is the issue with the HTML Standard?

In #9856 @noamr added the activation API to navigation.

Part of that update was the addition of a few assertions as step 12.5 of apply the history step:

https://html.spec.whatwg.org/multipage/browsing-the-web.html#apply-the-history-step

Switch on navigationType:

"reload"

Assert: targetEntry's document state's reload pending is true.

"traverse"

Assert: targetEntry's document state's ever populated is true.

"replace"

Assert: targetEntry's step is displayedEntry's step and targetEntry's document state's ever populated is false.

"push"

Assert: targetEntry's step is displayedEntry's step + 1 and targetEntry's document state's ever populated is false.

However, the navigationType variable is passed in as a NavigationType-or-null.

Is there a standard practice for switching on or-null variables where the null state is simply ignored?

Or is there a missing update to the rest of the spec to always pass a navigation type? or a missing default value?

@domenic
Copy link
Member

domenic commented Jan 25, 2024

I don't think spec "switches" are defined rigorously enough to say whether they must be exhaustive or not. It's reasonable to interpret the current text as just not performing any steps when the value doesn't hit any of the cases.

However, if there is a reasonable thing to assert in the null case (which occurs for navigable creation/destruction updates), then we could add a clause there.

@domenic domenic added clarification Standard could be clearer topic: navigation labels Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer topic: navigation
Development

No branches or pull requests

3 participants
@domenic @ADKaster and others