Add WebDriver support #282
Comments
rakuco
pushed a commit
that referenced
this issue
Jun 14, 2024
Related to #282: we need these algorithms to be properly defined in order to be able to support WebDriver and fake pressure states. This somewhat big change intends to clarify what "activate" and "deactivate" data delivery actually mean, as there used to be just a "data delivery" algorithm and no accompanying definitions for those two verbs. Furthermore, the data delivery algorithm itself was confusing: - It referenced a `data` variable in its declaration that was never passed by any callers. - `data` was of an implementation-defined type and format, but the steps assumed it had some associated information like source type that was not set anywhere. Fixing the above has required changes in different layers: - The "platform collector" concept, which used to be an abstract entity with which all globals interacted to retrieve telemetry data for all source types, is now a per-global and per-source type concept. The lower-level concept that represents a cross-global interface for the hardware or OS is now a "pressure source", which contains a snapshot of the latest reading it has retrieved along with a timestamp. - "Data delivery" is now called "data collection". It uses a platform collector and its associated pressure source to retrieve a telemetry sample that is transformed into a pressure state. - There are algorithms for activating and deactivating data collection. Both ensure they data collection cannot be started/stopped if they have already been. - `PressureObserver.observe()`'s had a "is not a valid source type" check that was too vague, as this step determined whether a given source type is supported by the platform or not, but the definition of "valid source type" was something else entirely. This step has been replaced by a sequence of steps that attempts to retrieve an existing platform collector for a source type and, if one does not exist, tries to connect to a corresponding pressure source. This change makes the same platform collector be used for all observers of a given source type and lays out in more detail what it means to check whether a source type is valid or not in this context. Co-authored with @kenchris in #265. It was split off as a separate pull request to make it easier to review and understand.
rakuco
pushed a commit
that referenced
this issue
Jun 14, 2024
#283) Related to #282: we need these algorithms to be properly defined in order to be able to support WebDriver and fake pressure states. This somewhat big change intends to clarify what "activate" and "deactivate" data delivery actually mean, as there used to be just a "data delivery" algorithm and no accompanying definitions for those two verbs. Furthermore, the data delivery algorithm itself was confusing: - It referenced a `data` variable in its declaration that was never passed by any callers. - `data` was of an implementation-defined type and format, but the steps assumed it had some associated information like source type that was not set anywhere. Fixing the above has required changes in different layers: - The "platform collector" concept, which used to be an abstract entity with which all globals interacted to retrieve telemetry data for all source types, is now a per-global and per-source type concept. The lower-level concept that represents a cross-global interface for the hardware or OS is now a "pressure source", which contains a snapshot of the latest reading it has retrieved along with a timestamp. - "Data delivery" is now called "data collection". It uses a platform collector and its associated pressure source to retrieve a telemetry sample that is transformed into a pressure state. - There are algorithms for activating and deactivating data collection. Both ensure they data collection cannot be started/stopped if they have already been. - `PressureObserver.observe()`'s had a "is not a valid source type" check that was too vague, as this step determined whether a given source type is supported by the platform or not, but the definition of "valid source type" was something else entirely. This step has been replaced by a sequence of steps that attempts to retrieve an existing platform collector for a source type and, if one does not exist, tries to connect to a corresponding pressure source. This change makes the same platform collector be used for all observers of a given source type and lays out in more detail what it means to check whether a source type is valid or not in this context. Co-authored with @kenchris in #265. It was split off as a separate pull request to make it easier to review and understand.
rakuco
pushed a commit
that referenced
this issue
Jun 14, 2024
Add WebDriver endpoints which allow manipulating virtual pressure sources, which are pressure sources whose behavior and samples are entirelly user-controlled. Also contrary to regular pressure sources, the provided samples (or, in spec parlance, a virtual pressure source's latest sample's data) are already PressureState instances rather than raw telemetry data that will be transformed into an adjusted pressure state. Caveats: - Shared workers are unsupported at the moment (i.e. the WebDriver endpoints only have an effect on Window and DedicaredWorkerGlobalScope globals). Storing virtual pressure source information in a top-level traversable does not play well with shared workers, for which the concept is somewhat irrelevant. We need to think of a different solution in the future if support for shared workers is important. - Once `PressureObserver.observe()` resolves, the same platform collector will be used until `disconnect()` or `unobserve()` are called. In other words, if a PressureObserver instance is active and using a real pressure source, adding a virtual pressure source of the same type will only have an effect on it and other instances in the same global once they all disconnect from the existing pressure source first. In terms of changes to the existing algorithms and concepts: - A top-level traversable has a mapping of source types to virtual pressure sources that is manipulated by the WebDriver endpoints. - When creating a new platform collector, `PressureObserver.observe()` first attempts to use a virtual pressure source when one exists and can be used. - The data collection algorithm distinguishes between the data format used by a virtual pressure source (which already is a PressureState) and by a real pressure source (which needs to be transformed into a PressureState). Co-authored with @kenchris in #265. It was split off as a separate pull request to make it easier to review and understand. Fixes #282.
rakuco
pushed a commit
that referenced
this issue
Jun 14, 2024
Add WebDriver endpoints which allow manipulating virtual pressure sources, which are pressure sources whose behavior and samples are entirelly user-controlled. Also contrary to regular pressure sources, the provided samples (or, in spec parlance, a virtual pressure source's latest sample's data) are already PressureState instances rather than raw telemetry data that will be transformed into an adjusted pressure state. Caveats: - Shared workers are unsupported at the moment (i.e. the WebDriver endpoints only have an effect on Window and DedicaredWorkerGlobalScope globals). Storing virtual pressure source information in a top-level traversable does not play well with shared workers, for which the concept is somewhat irrelevant. We need to think of a different solution in the future if support for shared workers is important. - Once `PressureObserver.observe()` resolves, the same platform collector will be used until `disconnect()` or `unobserve()` are called. In other words, if a PressureObserver instance is active and using a real pressure source, adding a virtual pressure source of the same type will only have an effect on it and other instances in the same global once they all disconnect from the existing pressure source first. In terms of changes to the existing algorithms and concepts: - A top-level traversable has a mapping of source types to virtual pressure sources that is manipulated by the WebDriver endpoints. - When creating a new platform collector, `PressureObserver.observe()` first attempts to use a virtual pressure source when one exists and can be used. - The data collection algorithm distinguishes between the data format used by a virtual pressure source (which already is a PressureState) and by a real pressure source (which needs to be transformed into a PressureState). Co-authored with @kenchris in #265. It was split off as a separate pull request to make it easier to review and understand. Fixes #282.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the time of writing, this specification does not have an Automation section and no WebDriver endpoints. This makes it difficult for users to include this API into their existing tests, as well as for implementers and spec editors to write interoperable web tests in WPT.
The text was updated successfully, but these errors were encountered: