Specify navigateEvent.downloadRequest #218
Conversation
README.md
Outdated
| @@ -405,7 +407,7 @@ Sometimes it's desirable to handle back/forward navigations specially, e.g. reus | |||
| ```js | |||
| navigation.addEventListener("navigate", e => { | |||
| // As before. | |||
| if (!e.canTransition || e.hashChange) { | |||
| if (!e.canTransition || e.hashChange || e.requestDownload !== null) { | |||
There was a problem hiding this comment.
I wish there were a way to make this truthy for <a download href="...">. I feel like if (!e.requestDownload) might be a common mistake, which such no-filename download=""s would trigger.
The only things I can think of are:
- Use a sentinel filename like
"unknown"for the<a download>case. (Ick.) - Use two fields,
downloadRequestedanddownloadRequestFilename. (Feels like a lot of API surface for such an edge case.)
|
Yeah, that's fair. I'll also propose a slight renaming in #76. |
Co-authored-by: Anne van Kesteren <[email protected]>
domenic
changed the title
| @@ -1216,6 +1240,7 @@ The <dfn attribute for="NavigationDestination">sameDocument</dfn> getter steps a | |||
| To <dfn>fire a traversal `navigate` event</dfn> at a {{Navigation}} |navigation| given a [=session history entry=] <dfn for="fire a traversal navigate event">|destinationEntry|</dfn>, and an optional [=user navigation involvement=] <dfn for="fire a traversal navigate event">|userInvolvement|</dfn> (default "<code>[=user navigation involvement/none=]</code>"): | |||
|
|
|||
| 1. Let |event| be the result of [=creating an event=] given {{NavigateEvent}}, in |navigation|'s [=relevant Realm=]. | |||
| 1. Set |event|'s [=NavigateEvent/classic history API serialized data=] to null. | |||
There was a problem hiding this comment.
I don't immediately see why this is necessary?
There was a problem hiding this comment.
This is kind of an unrelated bug fix where I'm trying to initialize all the fields of NavigateEvent every time I create it. Previously the language around classic history API serialized data was imprecisely talking about being "used conditionally" and then assuming that meant it was OK to not initialize it.
Closes #76.
@natechapin, please review!
@smaug---- @annevk any review you have time to provide would help validate that this is precise enough to be implemented interoperably, despite building on shaky foundations.
Preview | Diff