- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Jan 2024 10:19:06 +0000
- To: public-css-archive@w3.org
> > once when the navigation is initiated and send that boolean to the browser process, and once right before pageconceal, given that it was blocking due to the opt-in being there when the navigation was initiated. We cannot read the opt-in directly in the browser process. > > Specs shouldn't have a concept of browser vs renderer process, this should be an implementation detail. Not exactly. 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). > This is the flow of events: > > 1. Navigation is initiated. > 2. We have the final network response (in the browser process). > > 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: > > * The browser sends an IPC to the renderer to evaluate the opt-in. > * The renderer replicates the renderer's CSS state in the browser. > > Do you see any issue with this? 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. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9819#issuecomment-1905729692 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 23 January 2024 10:19:08 UTC