+1 to documenting Chromium's behavior in an evergreen format even if this isn't formally specified. I am constantly getting questions from developers about this and it is driving FUD about the capability of the web platform.
On Tue, Mar 26, 2024 at 7:47 PM Domenic Denicola <dome...@chromium.org> wrote: > LGTM3. > > With my HTML Standard editor hat on, I agree that this area does not > benefit from tight specification. > > However, in the past we've seen web developers be pretty confused by what > each browser's behavior is, for this and other inactive-tab / > offscreen-iframe / etc. throttling behaviors. Would it be possible to have > some sort of document summarizing Chromium's timer throttling behavior? > Probably the easiest would be in the source tree, but an evergreen article > on developer.chrome.com or MDN would also be great. (This feedback is > optional and does not block shipping.) > > On Wednesday, March 27, 2024 at 4:02:00 AM UTC+9 Mike Taylor wrote: > >> LGTM2 >> On 3/26/24 1:27 PM, Yoav Weiss (@Shopify) wrote: >> >> LGTM1 >> >> On Monday, March 25, 2024 at 4:42:55 PM UTC+1 Mike Taylor wrote: >> >>> Thank you for the answers Etienne. Once the Testing bit has been >>> requested, I'm happy to give an LGTM. >>> On 3/25/24 11:08 AM, Etienne Pierre-doray wrote: >>> >>> Right - that's my question. I also asked how similar this change is to >>>> whatever Safari implements - do they also align wakeups of JS timers for >>>> cross-origin, < 75% of viewport, frames that haven't yet received a user >>>> gesture? You previously wrote "non-interacted cross origin frames" for >>>> WebKit. Is there also a viewport condition? >>>> >>> I don't think WebKit has a viewport condition. [code >>> <https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/Document.cpp#L4005> >>> ] >>> >>> >>>> I believe the question Mike asked is not if this is spec compliant, but >>>> if the specifics of this should be more tightly specified, given that both >>>> WebKit and Chromium find a similar intervention useful. >>> >>> Defining this concept in the spec would presumably be used to more >>> strictly define when throttling is allowed (1) or mandatory (2) by >>> browsers. I really don't think it's useful to specify this more tightly in >>> the spec, as it makes performance interventions overly restrictive and is >>> prone to rotting over time, as common patterns and APIs evolve. >>> 1- Allowing throttling *only* for some definition of unimportant frames >>> could provide a more predictable platform to web devs, but it seems overly >>> restrictive on what the platform is allowed to do, and locks us in wrt. the >>> kind of performance intervention we're allowed to do. This is already not >>> true: both Webkit and blink implement various throttling in power-reducing >>> situations other than unimportant frames. >>> 2- It's unclear how making throttling mandatory in certain situations >>> brings value to web devs, especially if the intervention is different among >>> browsers. It does however add unnecessary constraints on the platform. >>> As a case in point, the spec specifies a mandatory 4ms delay on >>> settimeout (8.6.5 >>> <https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers>) >>> with a nesting level greater than 5. This intervention doesn't really make >>> sense in modern day browsers, and neither blink or webkit are spec >>> compliant (in distinct ways). >>> >>> >>> On Fri, Mar 22, 2024 at 2:57 PM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> On 3/22/24 1:37 AM, Yoav Weiss (@Shopify) wrote: >>>> >>>> >>>> On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen <zheda.c...@intel.com> >>>> wrote: >>>> >>>>> The privacy/security/enterprise/debuggability gates are requested on >>>>> Chrome Status. Testing gate to be requested later. >>>> >>>> Thanks - we've been asked to not send LGTMs until all bits have been >>>> requested. Can you let us know when Testing is? >>>> >>>> >>>>> "Unimportant" cross origin frames means they are cross-origin, visible >>>>> but use non-large proportion (<75%) of page's visible area and have not >>>>> received a user gesture. All 3 conditions should be met. The criteria are >>>>> too long so we use "unimportant" concept here. >>>>> >>>> Thank you - that's much more clear to me now. >>>> >>>> >>>>> This intervention is spec-compliant. The spec mentions "the >>>>> SetTimeout/SetInterval API does not guarantee that timers will run exactly >>>>> on schedule. Delays due to CPU load, other tasks, etc, are to be >>>>> expected". >>>>> The wait length of time is implementation-defined, "which is intended to >>>>> allow user agents to pad timeouts as needed to optimize the power usage of >>>>> the device". In Safari, DOM timers of non-interacted cross origin >>>>> frames are aligned to 30ms after reaching max nesting level (>=5). In >>>>> Firefox, all DOM timers of frames (both same origin and cross origin) are >>>>> aligned to 16ms. See details in "Interoperability and Compatibility >>>>> Risks", "Safari views", "Firefox views". >>>>> >>>> >>>> I believe the question Mike asked is not if this is spec compliant, but >>>> if the specifics of this should be more tightly specified, given that both >>>> WebKit and Chromium find a similar intervention useful. >>>> >>>> Right - that's my question. I also asked how similar this change is to >>>> whatever Safari implements - do they also align wakeups of JS timers for >>>> cross-origin, < 75% of viewport, frames that haven't yet received a user >>>> gesture? You previously wrote "non-interacted cross origin frames" for >>>> WebKit. Is there also a viewport condition? >>>> >>>> >>>> >>>>> On Thursday, March 21, 2024 at 1:27:16 AM UTC+8 mike...@chromium.org >>>>> wrote: >>>>> >>>>>> You should be able to see all the various bits for approvals in your >>>>>> chromestatus entry now, can you fill them out please? >>>>>> >>>>>> There have been a few questions/comments about the lack of clarity of >>>>>> what "unimportant cross-origin frames" are. What exactly is the >>>>>> definition? >>>>>> You mention that Safari has a similar intervention - how similar is it? >>>>>> Do >>>>>> we know? I wonder if there is alignment for this "unimportant >>>>>> cross-origin >>>>>> frame" concept, if we shouldn't specify that somehow. >>>>>> On 3/15/24 2:58 AM, Zheda Chen wrote: >>>>>> >>>>>> *Intent to Ship: Add JavaScript timer wake up alignment for >>>>>> unimportant cross-origin frames* >>>>>> >>>>>> Contact emails >>>>>> zheda...@intel.com, fdo...@chromium.org >>>>>> >>>>>> Specification >>>>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html >>>>>> >>>>>> Summary >>>>>> >>>>>> Align wake ups of JavaScript timers for unimportant cross-origin >>>>>> frames. Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] >>>>>> due to performance concerns. This is very conservative and actually some >>>>>> unimportant frames are eligible to use JS timer alignment. WebKit uses >>>>>> the >>>>>> policy to align DOM timer of non-interacted cross origin frames to 30ms. >>>>>> This feature adds JavaScript timer wake up alignment for unimportant >>>>>> frames >>>>>> on foreground pages. Unimportant frames means they are cross origin, >>>>>> visible but have non-large proportion of page’s visible area, and have no >>>>>> user interaction. The alignment interval is 32ms. [1] >>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/4589092 >>>>>> >>>>>> >>>>>> Blink component >>>>>> Blink>PerformanceAPIs>Timers >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3ETimers> >>>>>> >>>>>> TAG review >>>>>> None >>>>>> >>>>>> TAG review status >>>>>> Not applicable >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> "Other vendors already have interoperable implementation" Safari has >>>>>> a similar intervention. DOM timers of non-interacted cross origin frames >>>>>> are aligned to 30ms. In Firefox, all DOM timers (both same-origin and >>>>>> cross-origin) in foreground pages would be aligned to 16ms. "A mature >>>>>> specification in the relevant standards body" This intervention is >>>>>> spec-compliant. The spec mentions "the SetTimeout/SetInterval API does >>>>>> not >>>>>> guarantee that timers will run exactly on schedule. Delays due to CPU >>>>>> load, >>>>>> other tasks, etc, are to be expected. ". The wait length of time is >>>>>> implementation-defined, "which is intended to allow user agents to pad >>>>>> timeouts as needed to optimize the power usage of the device. " >>>>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html >>>>>> "A shared test suite for that specification" It isn't clear what should >>>>>> be >>>>>> tested specifically for this intervention since the spec allows waiting >>>>>> for >>>>>> an "implementation-defined" length. >>>>>> >>>>>> >>>>>> *Gecko*: Shipped/Shipping >>>>>> In Firefox, all DOM timers of frames (both same origin and cross >>>>>> origin) are aligned to 16ms >>>>>> >>>>>> *WebKit*: Shipped/Shipping >>>>>> In Safari, DOM timers of non-interacted cross origin frames are >>>>>> aligned to 30ms after reaching max nesting level (>=5) >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>> Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> Yes >>>>>> >>>>>> This intervention doesn't require changes to the spec. Timers are >>>>>> already covered by Web Platform Tests. >>>>>> >>>>>> >>>>>> Flag name on chrome://flags >>>>>> None >>>>>> >>>>>> Finch feature name >>>>>> ThrottleUnimportantFrameTimers >>>>>> >>>>>> Requires code in //chrome? >>>>>> False >>>>>> >>>>>> Tracking bug >>>>>> https://issues.chromium.org/issues/40942028 >>>>>> >>>>>> Launch bug >>>>>> https://issues.chromium.org/issues/40942028 >>>>>> >>>>>> Estimated milestones >>>>>> Shipping on desktop >>>>>> 123 >>>>>> DevTrial on desktop >>>>>> 121 >>>>>> Shipping on Android >>>>>> 123 >>>>>> DevTrial on Android >>>>>> 121 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> None >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5106220399853568 >>>>>> >>>>>> Links to previous Intent discussions >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> >>>>>> On Friday, March 15, 2024 at 6:24:06 AM UTC+8 mike...@chromium.org >>>>>> wrote: >>>>>> >>>>>> The privacy and security teams review all intents, so requesting >>>>>> reviews and answering the relevant questionnaires is the best path >>>>>> forward. >>>>>> >>>>>> Looking forward to the new I2S - thanks! >>>>>> On 3/14/24 11:22 AM, Zheda Chen wrote: >>>>>> >>>>>> More details are updated in ChromeStatus, including interoperability >>>>>> and compatibility risks, Safari/Firefox views, web platform tests. It >>>>>> compares the behaviors across different browser vendors. >>>>>> https://chromestatus.com/feature/5106220399853568 >>>>>> >>>>>> Will send the updated "intent to ship" to this thread later if it >>>>>> looks good. >>>>>> >>>>>> AFAIK, I don't see potential privacy/security issues, so can i set >>>>>> "security review status" and "privacy review status" to "not applicable"? >>>>>> Please let us know if you have any concerns. >>>>>> >>>>>> On Wednesday, March 13, 2024 at 10:00:35 AM UTC+8 dom...@chromium.org >>>>>> wrote: >>>>>> >>>>>> Can you fill out the interoperability and compatibility risks section >>>>>> here? I don't think standards position requests are necessary, but saying >>>>>> how this behavior might break existing sites that assume Chromium's >>>>>> current >>>>>> behavior, and how this new behavior compares to WebKit and Gecko, would >>>>>> be >>>>>> helpful. >>>>>> >>>>>> Also, can you request the >>>>>> privacy/security/enterprise/debuggability/testing gates on Chrome Status? >>>>>> >>>>>> On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen <zheda...@intel.com> >>>>>> wrote: >>>>>> >>>>>> Okay I update the process stage in Chrome Platform Status, and paste >>>>>> the newly-generated Intent above. Please take a look. >>>>>> >>>>>> https://chromestatus.com/feature/5106220399853568 >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7b8b9b84-2285-4fa9-a80d-c5fc0c1c0c41n%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7b8b9b84-2285-4fa9-a80d-c5fc0c1c0c41n%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20b3b7c6-780b-4715-9507-cd53cb5b1e29n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20b3b7c6-780b-4715-9507-cd53cb5b1e29n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMZz2QcZF6MPhp9vdi9RNJDgMfMcDkicGfLRGqNX-GTOwQ%40mail.gmail.com.
