fix some WPTs to not re-use the same 'valid once per session' auth landing, which incorrectly causes test-failures.
Differential Revision: https://phabricator.services.mozilla.com/D22878
--HG--
extra : moz-landing-system : lando
Bug 1522547 fixed the issue causing these tests to crash on shutdown, which was
also resulting in asan crashes, so these can be re-enabled.
Differential Revision: https://phabricator.services.mozilla.com/D22731
--HG--
extra : moz-landing-system : lando
Changes:
- added expected outcomes to various tests under `testing/web-platform/meta/encrypted-media` and `testing/web-platform/mozilla/meta/dom/throttling`
- this should address most of the failures in `wpt-7` in the linked try run
Carried over from abandoned diff D22742:
Bug 1531484 - disable dom/media/test/test_temporary_file_blob_video_plays.html
Bug 1526064 - disable dom/media/mediasource/test/test_MediaSource_flac_mp4.html
Bug 1526080 - disable dom/media/test/test_can_play_type_mpeg.html
Bug 1531851 - disable dom/media/webaudio/test/test_ScriptProcessorCollected1.html
Differential Revision: https://phabricator.services.mozilla.com/D22743
--HG--
extra : moz-landing-system : lando
The existing linear gradient shader is quite slow, especially
on very large gradients on integrated GPUs.
The vast majority of gradients in real content are very simple
(typically < 4 stops, no angle, no repeat). For these, we can
run a fast path to persist a small gradient in the texture cache
and draw the gradient via the image shader.
This is _much_ faster than the catch-all gradient shader, and also
results in better batching while drawing the main scene.
In future, we can expand the fast path to handle more cases, such
as angled gradients. For now, it takes a conservative approach,
but still seems to hit the fast path on most real content.
Differential Revision: https://phabricator.services.mozilla.com/D22445
--HG--
extra : moz-landing-system : lando
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
--HG--
extra : moz-landing-system : lando
Feature policy is currently only enabled in Nightly. This lets it pass on beta and release.
Differential Revision: https://phabricator.services.mozilla.com/D22397
--HG--
extra : moz-landing-system : lando
The spec mandates that only the paths of the URIs resulting from evaluation
of the Service-Worker-Allowed header and the registration's scope be compared,
yet Gecko also includes the origin in the comparison. This commit makes Gecko
follow the spec.
Differential Revision: https://phabricator.services.mozilla.com/D21970
--HG--
extra : moz-landing-system : lando
Unfortunately, we can't do fuzzy annotations in WPT yet. When we can, we should
adjust this annotation to "1px allowed to differ by <=8 in any color channel".
--HG--
extra : amend_source : c47d4d64056b795f6ad09124a7a862c7249d20f2
This patch avoids a potential division by 0 (one that's unlikely to be
triggered by real content), for correctness and robustness.
This patch isn't really changing the logic, because the newly-guarded code is
already guarded by a "length < sum" check, and "length" is expected to be
nonnegative [1], which means "sum" would already have been nonzero in cases
where the existing strict less-than comparison returned true.
[1] One special case where we can have negative `length` values here:
if this is an outline with an `outline-offset` that is sufficiently negative
to entirely cancel out the outlined element's border-box size, then that can
produce a negative `length` (i.e. the outline box will have a negative size,
conceptually). In that scenario, we were previously dividing by 0 here and
working with bogus huge/infinite negative values as a result, but we should
not do that.
Depends on D21578
Differential Revision: https://phabricator.services.mozilla.com/D21579
--HG--
extra : moz-landing-system : lando
This also adopts the resolution from [1] while at it, making letter-spacing
compute to a length, serializing 0 to normal rather than keeping normal in the
computed value, which matches every other engine.
This removes the SMIL tests for percentages from letter-spacing since
letter-spacing does in fact not support percentages, so they were passing just
by chance.
[1]: https://github.com/w3c/csswg-drafts/issues/1484
Differential Revision: https://phabricator.services.mozilla.com/D21850
--HG--
extra : moz-landing-system : lando
word-spacing is still using the old Gecko computed style storage, which means
that it has a little bit of precision loss that I just fixed for stroke-width.
As it turns out we need this to avoid losing precision both during painting and
during serialization.
This patch also changes to serialize `context-value` if it's the computed value.
I could keep the previous behavior, but it makes no sense to serialize the
initial value. We're the only ones to support this value anyway, and I couldn't
find a definition or spec for this.
Also update tests and expectations for:
* New unexpected passes.
* Always serializing the unit in getComputedStyle.
* Calc and interpolation support.
Chrome also always serializes the unit in getComputedStyle, so I'm pretty sure
this is compatible with them. Chrome is inconsistent and keeps numbers in
specified style, but that's inconsistent with itself and with other quirky
lengths, so I updated the tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D21819
Per spec these should just go directly to the expando object; we were ignoring them instead.
Differential Revision: https://phabricator.services.mozilla.com/D16930
--HG--
extra : moz-landing-system : lando
The main behavior changes are:
1) We no longer create a new Window when doing document.open(). We use the
same Window but remove all the event listeners on it and on the existing DOM
tree before removing the document's existing kids.
2) We no longer create a new session history entry. The existing one always
gets replaced instead.
3) We now support document.open on documents that are not in a Window.
The reasons for the various test changes are as follows:
The change to browser_modifiedclick_inherit_principal.js is because we no
longer set the docshell to a wyciwyg URL when document.open() happens and the
test was depending on that to terminate.
browser_wyciwyg_urlbarCopying.js is being removed because it's trying to test
wyciwyg URIs, which no longer exist.
The changes in docshell/test/navigation are because document.open() no longer
affects session history. One of the tests was testing the interactions there
and is being removed; another is being repurposed to just test that
document.open() does not affect history.length.
The change to test_x-frame-options.html is because document.open() now removes
event listeners on the window, which it didn't use to do (and in the specific
case in this test reused the existing inner too, so the listener was still
around in practice). The new behavior matches other browsers.
The removal of test_bug172261.html is because document.open() no longer affects
session history, so you can't go back across it or forward to the "opened"
state, so the situation that test is trying to test no longer exists.
The changes to test_bug255820.html are because reloading a document after
document.open() will now just load the URL of the document that was the entry
document for the open() call, not reload the written content. So there's not
much point testing reload behavior, and in this test it was just reloading the
toplevel test file inside the frames.
The change to test_bug346659.html is because now we no longer create a new
Window on document.open().
The change to test_bug1232829.html is because document.open() (implicit in this
test) no longer adds history entries, so the back() was just leaving the test
page instead of going back across the document.open(). The test is a
crashtest in practice, so might still be testing something useful about how
document.open() interacts with animations.
The change to test_bug715739.html is because the URL of the document after
document.open() is now the URL of the entry document, not a wyciwyg URL, so
reload() has different behavior than it used to.
The change to test_bug329869.html is because now when we go back we're
reloading the original document we had, not doing a wyciwyg load, and the
security info now doesn't include the untrusted script.
The changes to the wpt expectations are removing a bunch of expected failures
now that we pass those tests and disabling some tests that are fundamentally
racy and hence fail randomly. The latter all have github issues filed for the
test problem.
The change to testing/web-platform/tests/common/object-association.js is fixing
tests that were not matching the spec (and were failing in other browsers).
The change to parser-uses-registry-of-owner-document.html is fixing tests that
were not matching the spec (and were failing in other browsers).
The change to document-write.tentative.html is because the test was buggy: it
was using the same iframe element for all its tests and racing loads from some
tests against API calls from other tests, etc. It's a wonder it ever managed
to pass, independent of these patches (and in fact it doesn't pass according to
wpt.fyi data, even in Firefox).
The changes in html/browsers/history/the-history-interface are because
document.open() no longer adds history entries. The test was failing in all
other browsers for the same reason.
The changes in html/browsers/history/the-location-interface are because
reloading a document.open()-created thing now loads the URL of the page that
was the entry document for the open() call. The test was failing in all other
browsers.
The change to reload_document_open_write.html is because we now reload the url
of the document that entered the script that called open() when we reload, not
the written content. Other browsers were failing this test too; Gecko with
the old document.open implementation was the only one that passed.
The change to http-refresh.py is to fix a test bug: it was not returning a
Content-Type header, so we were putting up helper app dialogs, etc.
The change to test_ext_contentscript.js is because we no create a new global
for document.open() calls. Kris Maglione OKed this part.
Differential Revision: https://phabricator.services.mozilla.com/D17323
--HG--
extra : moz-landing-system : lando
Update the expected result of web-platform test /service-workers/service-worker/fetch-csp.https.html to FAIL
Differential Revision: https://phabricator.services.mozilla.com/D21100
--HG--
extra : moz-landing-system : lando
When Selection changed into an editing host,
Selection::NotifySelectionListeners() moves focus to the editing host.
In this case, we've scrolled to the focused element because it's our consistent
and traditional behavior. However, Chrome does not behave so. Therefore,
we should not scroll in this case for compatibility with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D19141
--HG--
extra : moz-landing-system : lando
disable tests on windows 10 for intermittent failures in webdriver new_session tests.
Differential Revision: https://phabricator.services.mozilla.com/D20480
--HG--
extra : moz-landing-system : lando
