In test0(), we use the callback of `requestAnimationFrame` to know in which
eventloop (i.e. `Tick()`) we are. However, we may not trigger the callback
of `requestAnimationFrame` if we are not visible. This is an optimization
in Bug 1145439.
Detail:
We use `Document::ShouldThrottleFrameRequests()` to check if we should throttle
the frame requests in the current `Tick()`. This function returns true if we
didn't get painted during the last paint, so we are not visible, so throttle
the frame requests. Note that because we have to paint this document at least
once to unthrottle it, we will drop one `requestAnimationFrame` frame when a
document that previously wasn't visible scrolls into view.
Therefore, we should make sure we got the first paint before running test0().
Using onload is not perfect, but we don't have other better choose for now.
Differential Revision: https://phabricator.services.mozilla.com/D29772
--HG--
extra : moz-landing-system : lando
Add multicol-width-004.html and multicol-width-005.html to test "width:
min-content" and "width: max-content" with column-span:all children.
There's no size containment in these tests.
Note it may be worth to reuse nsBlockFrame's mCachedMinISize and
mCachedPrefISize to cache intrinsic size for ColumnSetWrapperFrame, but
this can be done separately.
Differential Revision: https://phabricator.services.mozilla.com/D29616
--HG--
extra : moz-landing-system : lando
This ensures that the iframe is loaded by the time we query its visual viewport size.
Differential Revision: https://phabricator.services.mozilla.com/D30417
--HG--
extra : moz-landing-system : lando
This causes some scrollbar-related assertions to fail on desktop because
scrollbar behaviour with desktop zooming is not correct yet.
Differential Revision: https://phabricator.services.mozilla.com/D30415
--HG--
extra : moz-landing-system : lando
1. Add new tests with an extra argument of "content-box"/"border-box" in
observe(), and test contectBoxSize and borderBoxSize.
2. Add a new test for changing the writing mode. Changing writing mode makes
the element change the orientation, but the logical box size is still
the same, so we shouldn't fire the event.
Differential Revision: https://phabricator.services.mozilla.com/D28739
--HG--
extra : moz-landing-system : lando
I think it's better to make sure each test is independent from others, so we
create elements inside each test function. (Only change observe.html
because I touch only this file in this bug.)
Differential Revision: https://phabricator.services.mozilla.com/D29889
--HG--
extra : moz-landing-system : lando
In this patch, we support
1. content-box (default)
2. border-box
And let ResizeObserverEntry expose these box sizes.
Besides, we store the mLastReportedSize as the logical size.
Differential Revision: https://phabricator.services.mozilla.com/D28737
--HG--
extra : moz-landing-system : lando
According to the spec [1], the cue's end time might be negative and be smaller than its start time.
In this case, when we reach the cue's start on the media time line, we should treat it as a `missing cue` (which won't be actually displayed, but will receive events) when we run the `TimeMarchesOn`.
Therefore, we have to add this kind of cue into `otherCue` and let `TimeMarchesOn` handles it properly, to dispatch `enter` and `exit` event for it.
[1] https://html.spec.whatwg.org/multipage/media.html#text-track-cue-end-time
Differential Revision: https://phabricator.services.mozilla.com/D30242
--HG--
extra : moz-landing-system : lando
This patch does two changes in order to test the correct behavior.
(1) Not to use time out function
Waiting for 0.4s by using timeout function doesn't mean the code will exactly be executed after 0.4s.
If we would like to specify the time when we would like to change track's mode, we should listen for video's `timeupdate` to get the correct result.
(2) Modify ending condition
As this test is going to turn the track's mode to `showing/hidden` after video plays after 0.4s, the second and the third cue would be showed correctly.
The second cue is from 0.3 to 0.7, so when we changed track mode in 0.4s, the second cue would be regard as an active cue, and we would dispatched `enter` event on it. When the cue is going to become inactive, the event `exit` would be dispatched.
Therefore, there would be total 4 times of the accumulation of `enter` and `exit` events, which means `oncuechange` would also be dispatched 4 times.
Differential Revision: https://phabricator.services.mozilla.com/D30141
--HG--
extra : moz-landing-system : lando
The patch in bug 1507744 was not sufficient by itself, as the line-breaker could still accumulate a single "current word" across a text-run boundary, and then a single word-break value would be applied to it. We need to flush the line-breaker when word-break changes, so that each part of the word will have break opportunities set according to the appropriate value.
Differential Revision: https://phabricator.services.mozilla.com/D30260
--HG--
extra : moz-landing-system : lando
Tests 001-003 are fixed by the patch in this bug; 004-007 still fail in Firefox after the patch is applied.
(Safari passes all these tests; Chrome fails 004 and 007 in my testing.)
Differential Revision: https://phabricator.services.mozilla.com/D30192
--HG--
extra : moz-landing-system : lando
The test this is trying to annotate no longer exists, and we pass the new test.
Differential Revision: https://phabricator.services.mozilla.com/D30166
--HG--
extra : moz-landing-system : lando
When the host is omitted, a new socket will listen at any address,
which triggers the following firewall warning:
> Do you want the application "Python.app"
> to accept incoming network connections?
Since the default behavior without approval is to deny,
it should be safe to limit this to local connections only.
Doing so gets rid of the FIVE firewall prompts that appear when a wpt
test is started, for each server (http, https, http2, ws, wss).
While I'm at it, I've also fixed the port detection logic to not trigger
the firewall prompt (it appears at `mach wpt-serve`).
Differential Revision: https://phabricator.services.mozilla.com/D28541
--HG--
extra : moz-landing-system : lando
If we can't get corresponding cue, `getCueById()` will return `null`, not empty object. Therefore, we should use `assert_equals` instead.
Differential Revision: https://phabricator.services.mozilla.com/D29888
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
[css-properties-values-api] Absolutize initial <url> values.
The computed value would incorrectly remain relative for the initial value
of <url>-registered custom properties. This is because it did not undergo
the token-rewriting done for non-initial properties.
Since the token-rewriting function was implemented, circumstances have
changed a little: there is now a general absolutization mechanism (i.e.
StyleBuilderConverter::ConvertRegisteredPropertyVariableData). Therefore,
this CL performs the URL absolutization on the CSSValue-level rather than
the token level. This automatically also catches the initial-value case.
Note that CSSVariableDatas with var()-references would previously "forget"
their base URL and TextEncoding when resolved. This didn't matter in
practice, because we would already have rewritten the tokens at that point.
However, it matters now, since the URL is now made absolute _after_ the
CSSVariableData is resolved. Hence, CSSVariableData::CreateResolved has
gained the appropriate parameters.
R=futhark@chromium.org
Bug: 641877
Change-Id: I0fd80664adb49e60df24dcc0e91d23872f61fdb8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1528188
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646218}
--
wpt-commits: 2f2bf34086414fb3bd8e01e92aca1aa18e7ea730
wpt-pr: 16151
Automatic update from web-platform-tests
[css-flexbox] Correctly calculate min-height with justify-content
Spacing added by justification is not meaninfully part of the
intrinsic block size of an item; remove it.
This is especially problematic with percentage sizes, because
with height: 100% and justify-content: flex-end we would
position any flex items at the end and calculate a minimum
size based on the 100%, even though we ought to ignore percentages.
R=dgrogan@chromium.org, eae@chromium.org
Bug: 945214
Change-Id: If4e271df5e550807632d30e5dd1c2b3068d45313
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1546002
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646178}
--
wpt-commits: f326d29cb1469bf9b61d816a4752d02df706d129
wpt-pr: 16156
Automatic update from web-platform-tests
Honor contain:size correctly for multicol containers.
Updated the existing test for this to actually test with contain:size.
Bug: 863454
Change-Id: I44ac7bd4dd875845d14476dd9b286450bbc66bf0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1545302
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646173}
--
wpt-commits: b440056b54c783d18a78da25f8d31ce324e980f4
wpt-pr: 16150
