Other browsers appear to only do this for form submission, not for
all javascript URL navigations. Let's remove the handling in the
general javascript URL navigation handling so that our behaviour
diference to other browsers is limited specifically to form
elements, instead of the general case.
Unfortunately this does (expectedly) cause the test added in
3e0ea4f62 to start timing out, so that test is marked as skipped.
If we conform with the HTML specification by processing the iframe
synchronously as part of the iframe post connection steps, this test
will time out as the load event is fired in the appendChild call.
Create the promise for the load event before performing the load event
to handle this situation, which also allows the test to pass in
chromium.
This requires us to front load computation of writing-mode and direction
before we encounter any logical aliases or their physical counterparts
so that we can create a mapping context.
Doing this at compute rather than cascade time achieves a few things:
1) Brings us into line with the spec
2) Avoids the double cascade that was previously required to compute
mapping contexts
3) We now compute values of logical aliases, while
`style_value_for_computed_property` maps logical aliases to their
physical counterparts, this didn't account for all cases (i.e. if
there was no layout node, Typed OM, etc).
4) Removes a hurdle to moving other upstream processes (i.e. arbitrary
substitution function resolution, custom property computation) to
compute time as the spec requires.
The hover invalidation code only tried matching ::before/::after
selectors when has_pseudo_element() returned true, which requires an
existing layout node. A pseudo-element that doesn't exist yet (because
its content is only set by a hover rule) has no layout node, so the
match was skipped and hovering never triggered a style recompute.
Always try ::before/::after selectors during hover invalidation.
We no longer try to resolve calculated values at parse time which means
we support relative lengths.
We now clamp negative values rather than rejecting them at parse time.
Parsing has been inlined into `parse_ratio_value` and `parse_ratio` has
been removed since `parse_ratio_value` was the only caller
We only checked if the paintable box had scrollable overflow, but that
was too simple - we now use the same logic that checks whether a box can
be scrolled by a mousewheel event.
The autoscrolling test was updated as well to use rAF+rAF+timeout
instead of a fixed 1000ms timeout, which is prone to flakiness.
Imported WPT tests often load resources using canonical absolute paths,
for example:
/html/browsers/windows/resources/message-parent.html
Our usual strategy is to rewrite such URLs to relative paths during
import so they resolve from the importing test HTML file (which also
allows for loading this HTML as a file://).
That works for same-origin relative loading with the echo server, but it
breaks down when a test constructs a cross-origin URL from an absolute
path, for example:
get_host_info().REMOTE_ORIGIN + "/some/wpt/path.html"
In that case the resource still needs to be fetched at its canonical
absolute path, so rewriting it relative to the importing document is no
longer sufficient.
Update the HTTP test server so /static/ continues to serve from the
general test root, other non-echo requests are served from the imported
WPT tree, and dynamically registered echo responses live under /echo/
to avoid path conflicts.
Make some local file edits to get-host-info.sub.js such that
get_host_info() refers to the echo server through localhost,
and the cross origin server through 127.0.0.1.
This allows many imported WPT tests using this function work
correctly (if loaded from the echo HTTP server).
A test configured under LoadFromHttpServer is loaded over localhost
rather than 127.0.0.1, causing the echo server to be accessed
across origins. In general, the behavior being tested is intended
for same-origin scenarios, so update the echo server URL to use
localhost.
The beforeunload, promiserejection, beforetoggle and toggle events were
previously not tagged as trusted. This commit properly tags the event
so that we match the behaviour implemented by other browsers.
The form submit event was previously not tagged as trusted. This commit
properly tags the event so that we match the behaviour implemented by
other browsers and expected by WPT.
CSSPixelFraction::to_float() and to_double() were converting to
CSSPixels (6-bit fixed-point) before converting to float/double,
which truncated the result to 1/64 precision. For example, 500/2500
(= 0.2) became 12/64 (= 0.1875).
Fix by dividing the numerator and denominator as floats/doubles
directly, which is what every other browser engine does when
converting layout units to floating-point ratios.
This was an oversight in the original CSSPixelFraction implementation
(commit 8cd1f65507). The class was designed for lossless comparison
and multiply-then-divide operations (which stay in CSSPixels land),
and the to_float/to_double methods were convenience additions that
took the easy path through CSSPixels conversion without considering
the precision loss.
Per the spec, the observer's [[scrollMargin]] should be applied to
each scroll container's scrollport when walking the containing block
chain. This expands the effective clip rect, allowing targets to be
detected as intersecting before they actually enter the visible area
of the scroll container.
Add a scroll_margin_values() accessor to IntersectionObserver so the
raw LengthPercentage values can be used during intersection computation.
The scroll margin is applied by inflating the scroll container's
padding box rect before clipping the intersection rect against it.
Add a test that creates two observers watching the same target inside
an overflow:hidden container: one without scroll margin and one with
scrollMargin "50px". The target is partially visible (10px out of 50px).
Without scroll margin, the ratio is ~0.19 (10px visible / 50px target).
With scroll margin, the expanded scrollport should make the full target
visible (ratio=1), but currently both report the same ratio because
scroll margin is not yet applied in compute_intersection.
Implement the containing block chain traversal in compute_intersection
(steps 2-3 of the spec algorithm). Walk from the target's paintable box
up through the containing block chain, clipping the intersection rect
against each ancestor that has a content clip (overflow != visible).
This fixes the case where a target is inside an overflow:hidden or
overflow:clip container and pushed below the visible area. Previously,
the intersection ratio was incorrectly non-zero because we only
intersected with the root bounds (viewport), not intermediate
scroll containers.
Also update the scroll container clipping tests to verify the
intersection ratio (which is what compute_intersection affects)
rather than isIntersecting (which per spec is based on targetRect
vs rootBounds, not the clipped intersection rect).
Add tests for the implicit root case where targets are inside scroll
containers with various overflow types:
- overflow:hidden container with target pushed below visible area:
should NOT be intersecting (currently wrong, shows intersecting).
- overflow:clip container with target pushed below visible area:
should NOT be intersecting (currently wrong, shows intersecting).
- overflow:hidden container with target at top (visible):
should be intersecting (correct).
The two failing tests currently reflect wrong behavior because
compute_intersection does not clip against intermediate scroll
containers when walking the containing block chain.
The boolean logic in steps 2-3 of "run the update intersection
observations steps" was incorrect. The code used || between the two
negated skip conditions instead of &&, and the first sub-expression
had its negation inverted.
This caused intersection geometry to be computed (and callbacks fired)
for targets that are not descendants of an explicit element root,
as long as they spatially overlapped the root's bounding rect.
The spec says:
- Step 2: Skip if root is not implicit AND target not in same document.
- Step 3: Skip if root is Element AND target not descendant of root.
The enter condition is NOT(skip2) AND NOT(skip3), but we had
NOT(skip2) OR NOT(skip3) with a wrong negation in the first part.
Add tests verifying behavior when an IntersectionObserver has an
explicit element root:
- A target that is a descendant of the root should be reported as
intersecting when it overlaps the root.
- A target that is NOT a descendant of the root but spatially overlaps
it should NOT be reported as intersecting per spec step 3 of "run
the update intersection observations steps". The expected output
currently reflects the wrong (buggy) behavior.
These tests set up a delayed echo endpoint using a synchronous XHR to
http://127.0.0.1:PORT/echo, but the page itself is served from
http://localhost:PORT. This cross-origin request triggers a CORS
preflight, which intermittently fails with a NetworkError. There's
already a FIXME in place to get rid of the spin_until() that caused this
to happen.
Use a relative URL instead, since the page is already served from the
echo server.
Fixes#8564
Avoid comparing exact matrix3d values which contain floating point
noise that could differ across platforms. Instead, check whether the
transform is or isn't the identity matrix.
Per the CSS Transforms spec, when interpolating rotate3d() functions
with equal normalized direction vectors (or when one angle is zero),
the rotation angle should be interpolated numerically rather than
using quaternion slerp.
Previously we always used quaternion slerp, which cannot represent
rotations beyond 360 degrees. This meant that animating from
rotateY(0deg) to rotateY(3600deg) produced no visual animation, since
both quaternions are identical (3600 mod 360 = 0).
Now we detect when axes match and interpolate the angle directly,
correctly preserving multi-turn rotations. This fixes 168 WPT tests.
When interpolating between rotateY(0deg) and rotateY(3600deg), the
angle should be interpolated numerically. Currently we use quaternion
slerp which sees these as identical rotations (3600 mod 360 = 0),
producing no visual animation. A following commit will fix this.
Per the CSS Animations spec, the animation-timing-function property
describes how the animation progresses between each pair of keyframes,
not as an overall effect-level timing function.
Previously we set it as the effect-level timing function on the
AnimationEffect, which caused easing to be applied to the global
animation progress. This made animations with multiple keyframes
"pause" at the start and end of the full animation cycle instead of
easing smoothly between each pair of keyframes.
Now we:
- Store per-keyframe easing in ResolvedKeyFrame from @keyframes rules
- Store the default easing on CSSAnimation instead of on the effect
- Apply per-keyframe easing to the interval progress during
interpolation, falling back to the CSS animation's default easing
- Also store per-keyframe easing from JS-created KeyframeEffects to
avoid incorrectly applying CSS default easing to replaced effects
