[css-view-transitions-2] Separte MPA transition start from check #9819
Conversation
|
Still need to review the PR but one quick comment based on this statement.
The check should still be at 1 place after we have the final response. Because in the future it'll be based on the post redirect URL. We'll just run it in the browser (or parent process in Gecko?) to decide whether |
I hope this would become clearer with the HTML PR :) but in the meantime: We need to resolve the opt-in twice: once when the navigation is initiated and send that boolean to the browser process, and once right before |
Specs shouldn't have a concept of browser vs renderer process, this should be an implementation detail. This is the flow of events:
If we're evaluating the opt-in after 2) but before dispatching any events to the page, which implementation option we choose below wouldn't be web observable:
Do you see any issue with this? |
Not accurate :) Much of the navigation flow occurs "in parallel", which means in a different thread/process, in this case that's what represents the browser process. So if during an "in parallel" flow we want to read something from the document (like run an algorithm that reads styles from current CSS), we have to queue a task on that document (which would be equivalent to an IPC call).
The issue is that this IPC means an unnecessary round-trip in case there is no opt-in, or in case the opt-in was already there when we started the navigation. The way I've specified it in the PR is that we read it when starting the navigation, without that extra round-trip after the final response. |
css-view-transitions-2/Overview.bs
Outdated
|
|
||
| 1. If |oldDocument|'s [=environment settings object/origin=] is not [=same origin=] as | ||
| |newDocument|'s [=environment settings object/origin=] then call |onReady| and return. | ||
| 1. If |oldOrigin| is not [=same origin=] as |newOrigin| then return false. | ||
|
|
||
| 1. If |newDocument| [=was created via cross-origin redirects=] is true |
There was a problem hiding this comment.
There is an early return above for the "created with cross-origin redirects" case so we'll never hit this.
There was a problem hiding this comment.
Not exactly, but I'll move this bit to the HTML spec PR. A navigation was created with a cross-origin redirects if:
- the document was created with cross-origin redirects
- this is not a BFCache restore
See also w3c/csswg-drafts#9819. The pageswap event is specified here to work as follows: * It's sent whenever a document navigates away, to a different document, but not when unloaded for other reasons, such as closing the browser types or unloading an ancestor. * It includes a NavigationActivation object for same-origin navigations. * If the navigation might trigger a cross-document view-transition (this is determined when snapshotting the source document, by reading the CSS), pageswap is fired and then unloading is deferred until the old state is captured for the view transition. Otherwise, if the view transition is skipped, unloading happens immediately. Closes #9702.
See also w3c/csswg-drafts#9819. The pageswap event is specified here to work as follows: * It's sent whenever a document navigates away, to a different document, but not when unloaded for other reasons, such as closing the browser types or unloading an ancestor. * It includes a NavigationActivation object for same-origin navigations. * If the navigation might trigger a cross-document view-transition (this is determined when snapshotting the source document, by reading the CSS), pageswap is fired and then unloading is deferred until the old state is captured for the view transition. Otherwise, if the view transition is skipped, unloading happens immediately. Closes whatwg#9702.
In prepartion for the HTML integration and the
pageconcealevent, the check for whether cross-document view transition should take place is to be called twice from the HTML spec:pageconcealevent should be blockingpageconceal.So separating the algorithm and exporting the check.