Emilio Cobos Álvarez
Emilio Cobos Álvarez
The spec violation is, afaict, this line, because it assumes that new tasks won't be scheduled: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/page/page_animator.cc;l=145;drc=4268052f5025da8b928c9e59a04493b396acaad3 And yeah it seems nobody really properly implements the "collect all docs upfront"...
It seems blink does something close enough with regards to that, so maybe the spec is web compatible?
> @emilio Why does the test have log(t + childWin.performance.timeOrigin, "parent-from-parent"); ? Shouldn't it use parentWin Typo, yeah, fixed it up. > Isn't this test hitting the step 4. Unnecessary...
I'm not convinced I agree with that read of the spec. > the user agent believes that updating the rendering of doc's node navigable would have no visible effect; That's...
cc @smaug---- @EdgarChen @zcorpan @annevk @domfarolino
@progers how do you avoid rejecting for stuff like [image-decode-with-quick-attach.html](https://github.com/web-platform-tests/wpt/blob/1eaddc37a5/html/semantics/embedded-content/the-img-element/decode/image-decode-with-quick-attach.html)?
Ah, I found the blame: https://chromium-review.googlesource.com/c/chromium/src/+/1141121, so https://html.spec.whatwg.org/#reacting-to-dom-mutations: > The [img](https://html.spec.whatwg.org/#the-img-element) or [source](https://html.spec.whatwg.org/#the-source-element) [HTML element insertion steps](https://html.spec.whatwg.org/#html-element-insertion-steps) or [HTML element removing steps](https://html.spec.whatwg.org/#html-element-removing-steps) count the mutation as a [relevant mutation](https://html.spec.whatwg.org/#relevant-mutations) Is...
That comes from https://issues.chromium.org/40585250 but I don't have access to that. But ok, that's a bit unfortunate... It's a bit weird to have some relevant mutations that don't schedule a...
Open questions that I can think of: * Do we want `.decode()` to queue a microtask unconditionally? If there's no "update the image data" scheduled, it might be less confusing...
An (somewhat underwhelming) alternative would also be keeping the `.decode()` spec as is, and documenting that `HTMLImageElement` insertion is not a "relevant mutation" unless inside a `` element, but that...