Automatic update from web-platform-tests
Add expression representation to InterpolableLength
This is a second attempt of crrev.com/c/1777025, as the previous
attempt led to a performance regression.
As CSSLengthArray cannot represent all lengths, and in particular,
cannot represent lengths where min/max() are present, this patch
augments InterpolableLength with a CSSMathExpressionNode representation,
so that all lengths can be interpolated and animated.
Bug: 991672, 1002177
Change-Id: Ic8af313872b900eac2587531c56a8eca65d55a5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1805718
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Alan Cutter <alancutter@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698895}
--
wpt-commits: 086bc41857e0c2b0644b6ac2f8aa31f432743118
wpt-pr: 19109
Automatic update from web-platform-tests
[Trusted Types] De-flake trusted-types-eval-reporting test.
The WPT test trusted-types-eval-reporting was flaky, usually failing on the
first run, but succeeding on the second. This was a real (and potentially
serious) bug, where the CSP logic would rely on the V8 eval callback being
called, but other parts would blanket-allow eval (and hence suppress the
callback) because they didn't check for 'trusted types' condition.
Also, minor cleanups for the test.
Bug: 739170
Change-Id: I00699b115f0be474c2b6d231dcc8b884868248b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1807218
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698883}
--
wpt-commits: 034c163b81d6ae572869a98a80bed5bc8c52336d
wpt-pr: 19121
Automatic update from web-platform-tests
Allow the Ahem stylesheet to be loaded from support/ahem.css (#19218)
This means that the use of Ahem in the CSS vendor-imports/mozilla
directory can be linted, which prevents those tests accidentially
including Ahem without the import. It also provides the theoretical
ability for other directories to override the Ahem stylesheet without
removing all linting, which may be useful.
--
wpt-commits: 44002ecbc8839887a462d5844cde97a156cf02a0
wpt-pr: 19218
With clang-8 sources, this task was already pretty close to the limit with typical times of 54-58 minutes.
In clang-9, enough new code was added that we're seeing frequent intermittent timeouts. Even the few successful builds come in just under the wire at 60 minutes.
Note for sheriffs, if the clang-9 update gets backed out, this patch can stay, we'll need it anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47288
--HG--
extra : moz-landing-system : lando
The frame pointer register is non-volatile on all of our platforms.
Also note that we never saved the frame pointer for tail calls and this has
never been an issue.
Differential Revision: https://phabricator.services.mozilla.com/D46789
--HG--
extra : moz-landing-system : lando
As we roll out the TLS 1.0 and 1.1 deprecation, sites that don't support TLS 1.2
will show the neterror page. This adds a box to that page that shows in this
specific case. That box explains what is going on and gives an option to
re-enable TLS 1.0.
As mentioned, this will show alongside an option to reset TLS-related
preferences if any overrides are active.
Hitting the button will set the new pref to 'true' and reload the page.
Once the override is engaged, the option won't show, but that option to reset
preferences will show (as this is a TLS-related preference).
The intent is to remove this affordance in March 2020 as we formally move to
having TLS 1.2 the minimum version. All going to plan, this will only affect
prerelease channels, though anyone who has tweaked security.tls.version.* could
also see this.
Differential Revision: https://phabricator.services.mozilla.com/D45799
--HG--
extra : moz-landing-system : lando
The intent of adding this pref is to allow us to change defaults for
security.tls.version.min for a progressive rollout of a TLS 1.0 and 1.1
deprecation. During that process, we'd like to offer the option to enable these
old TLS versions, without adding a pref override that would cause those versions
to remain enabled once we finish the rollout.
Those people who have triggered the override will be able to access TLS 1.0 and
1.1 sites until we eventually remove the code that respects this pref. What is
likely to happen is that this pref will remain in code past the end of our
rollout for part of a release cycle, plus maybe the next cycle depending on
how timing works out.
This pref is a simple boolean that we'll remove in March 2020.
Differential Revision: https://phabricator.services.mozilla.com/D45798
--HG--
extra : moz-landing-system : lando
This flips the default for security.tls.version.min to 3 (TLS 1.2) for the
Nightly channel.
Having had this pref at this level for the last year, I can confirm that this
does break the occasional site, but it is quite rare. The intent of this change
is to start making it more obvious when sites don't support TLS 1.2.
I'm asking for wider review because this is a disruptive change.
Differential Revision: https://phabricator.services.mozilla.com/D45627
--HG--
extra : moz-landing-system : lando
This change updates the URL bar in Firefox Reality for Desktop to support
searching with the default provider when a not-well-formed URL is input by the
user.
Differential Revision: https://phabricator.services.mozilla.com/D47292
--HG--
extra : moz-landing-system : lando
For remote content documents, select dropdowns (for <select size="1">) are rendered in the parent process using a XUL menupopup.
This means that the accessibility code for HTML selects doesn't apply.
In the menupopup, the optgroup is a sibling of its contained options.
For accessibility, we want to preserve the hierarchy such that the options are inside the optgroup.
We do this using aria-owns on the optgroup item.
This required some tweaks to XULMenuitemAccessible, as it couldn't previously handle grouping Accessibles between the menupopup and its items.
Differential Revision: https://phabricator.services.mozilla.com/D43901
--HG--
extra : moz-landing-system : lando
The browser.windows.onCreated event is triggered before
browser.windows.create returns. Waiting until browser.windows.create has
resolved may resolve the memory leak from bug 1474041.
Differential Revision: https://phabricator.services.mozilla.com/D47106
--HG--
extra : moz-landing-system : lando
Adds a new event listener to `browser.urlbar` called `onResultPicked`. This event is fired for tip results when they don't specify a URL. Hypothetically it could be fired for any type of result that didn't specify a URL, but that's only tips for now.
The listener is passed two arguments: the payload of the result that was picked, and a "details" object whose properties depend on the type of result. For tips, details is `{ helpPicked }`, where `helpPicked` is true if the help button was picked and false if the main button was picked.
Differential Revision: https://phabricator.services.mozilla.com/D46254
--HG--
extra : moz-landing-system : lando
In bug1583978, we are going to remove `AudibleState::eMaybeAudible`. But before that, as `AudibleState::eMaybeAudible` is only used for delaying media playback, so we can remove its usage from media element and move it to the dedicated class to reduce confusion about how and when we should use `AudibleState::eMaybeAudible` or `AudibleState::eNotAudible`.
Differential Revision: https://phabricator.services.mozilla.com/D47153
--HG--
extra : moz-landing-system : lando
Modify test and some description naming from "block autoplay" to "delay autoplay" and split the blocking autoplay test to new independent task.
Differential Revision: https://phabricator.services.mozilla.com/D45106
--HG--
extra : moz-landing-system : lando
Current test cases are all about calling `video.play()`, we don't have test case for media with autoplay keyword.
Differential Revision: https://phabricator.services.mozilla.com/D44922
--HG--
extra : moz-landing-system : lando
As the things we do in those tests are not really "block" autoplay, which is not to allow autoplay starts, what we do is actually delaying them until tab goes to foreground or user clicking `play tab` icon on the tab.
In order to distinguish them from the real blocking-autoplay, and reflect what we really do in those tests, rename all of them with prefix "browser_delay_autoplay_*".
Differential Revision: https://phabricator.services.mozilla.com/D44921
--HG--
rename : toolkit/content/tests/browser/browser_block_autoplay_media.js => toolkit/content/tests/browser/browser_delay_autoplay_media.js
rename : toolkit/content/tests/browser/browser_block_autoplay_media_pausedAfterPlay.js => toolkit/content/tests/browser/browser_delay_autoplay_media_pausedAfterPlay.js
rename : toolkit/content/tests/browser/browser_block_multipleMedia.js => toolkit/content/tests/browser/browser_delay_autoplay_multipleMedia.js
rename : toolkit/content/tests/browser/browser_block_notInTreeAudio.js => toolkit/content/tests/browser/browser_delay_autoplay_notInTreeAudio.js
rename : toolkit/content/tests/browser/browser_block_autoplay_playAfterTabVisible.js => toolkit/content/tests/browser/browser_delay_autoplay_playAfterTabVisible.js
rename : toolkit/content/tests/browser/browser_block_playMediaInMuteTab.js => toolkit/content/tests/browser/browser_delay_autoplay_playMediaInMuteTab.js
rename : toolkit/content/tests/browser/browser_block_plugIn.js => toolkit/content/tests/browser/browser_delay_autoplay_plugIn.js
rename : toolkit/content/tests/browser/browser_block_silentAudioTrack_media.js => toolkit/content/tests/browser/browser_delay_autoplay_silentAudioTrack_media.js
rename : toolkit/content/tests/browser/browser_block_webAudio.js => toolkit/content/tests/browser/browser_delay_autoplay_webAudio.js
extra : moz-landing-system : lando
We could simply check `TabBlockEvent` to know whether we starts delaying media playback or not. We don't need to check media element's `computedSuspended`. Because `computedSuspended` is something, which was designed to get the internal suspended state of `AudioChannelWrapper`, in our case, as the delaying autoplay is not related to `AudioChannelWrapper` anymore, so the state we got actually couldn't reflect anything.
Differential Revision: https://phabricator.services.mozilla.com/D44920
--HG--
extra : moz-landing-system : lando
As we would show delay media playback icon for `eNotAudible` and `eMaybeAudible`, we should call `AudioChannelWindow::AudioAudibleChanged()` when we register the agent in order to notify a delaying start.
In the past, as we use `AudioChannelWrapper` to handle delaying, which would call `HTMLMediaElement::AudioChannelWrapper::WindowSuspendChanged()` immediately when we delay autoplay, and finally triggers `AudioChannelWindow::AudioAudibleChanged()` to notify sending block-start event. It's very unclear, so we should set it in the beginning if we have already know the audible state of delayed media.
Differential Revision: https://phabricator.services.mozilla.com/D44748
--HG--
extra : moz-landing-system : lando
Now `AudioChannelWrapper` would only start `AudioChannelAgent` when media starts and stop the agent when media stops. It won't handle any case with `SUSPENDED_BLOCK`.
It's clearer to know when we would start or stop the agent in AudioChannelWrapper.
In addition, in bug1577890, we will remove more unnecessary logic which is used for Fennec only in order to make `AudioChannelWrapper` cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D44747
--HG--
extra : moz-landing-system : lando
Separate the logic of delaying media playback from `HTMLMediaElement`'s `mAudioChannelWrapper` to a new class, because delaying media playback is a special usage of using `AudioChannelAgent`.
It would make the code cleaner and separate the normal usage and the special usage, to reduce confusion.
We usually start `AudioChannelAgent` when media playback starts and stop it when media playback stops, however, in this case, we would start the agent even if media hasn't be started yet, because we would like to use the agent as a connection with `AudioChannelService` in order to receive the resume command when we're able to play delayed playback.
Differential Revision: https://phabricator.services.mozilla.com/D44746
--HG--
extra : moz-landing-system : lando
As we have another usage to know whether media is audible or not, we remove this function from AudioChannelWrapper and make it as media element's function.
In addition, it also makes sense to have this function for media element, because the result is decided by media element's own attributes.
Differential Revision: https://phabricator.services.mozilla.com/D44744
--HG--
extra : moz-landing-system : lando
There are some checking conditions can be reordered or simplified in order to remove some unnecessary check.
Differential Revision: https://phabricator.services.mozilla.com/D47027
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Still getting some crash reports on nightly with a 1MB stack. Let's try one more time
with 2MB just to see if we can eliminate those. If this fails, then we may need to consider
more drastic approaches like disabling OMTP in this case.
Differential Revision: https://phabricator.services.mozilla.com/D47080
--HG--
extra : moz-landing-system : lando
This patch makes fragmentation in "column-fill:auto" mode possible.
Note that we only bail out of creating more column contents when
"column-fill:auto" mode is set from the styles, i.e. when mForceAuto is
false. That is because when mForceAuto is true, we usually in the case
where we have gave up balancing, and we really want to create overflow
columns.
Note: without `!aConfig.mForceAuto` check, 673770.html can generated
assertions, and the frame tree contains dangling Overflow-lines and
ExcessOverflowContainersList.
Differential Revision: https://phabricator.services.mozilla.com/D47005
--HG--
extra : moz-landing-system : lando
mUsedColCount is used in balancing mode to check whether we have created
the maximum number of columns when the content cannot fit. Similarly,
mUsedColCount can also be useful in "column-fill:auto" mode to improve
the fragmentation story in the next patch.
This patch doesn't change the behavior (yet).
Differential Revision: https://phabricator.services.mozilla.com/D47004
--HG--
extra : moz-landing-system : lando
In next patch, this variable won't be set to INT32_MAX in
"column-fill:auto" mode, and it will be used in Part 4. Hence the
rename.
Differential Revision: https://phabricator.services.mozilla.com/D47003
--HG--
extra : moz-landing-system : lando
The associated if-block has a "break" statement at the end of the scope
to break the while-loop, making the else-block redundant.
Differential Revision: https://phabricator.services.mozilla.com/D47002
--HG--
extra : moz-landing-system : lando
Adds a new event listener to `browser.urlbar` called `onResultPicked`. This event is fired for tip results when they don't specify a URL. Hypothetically it could be fired for any type of result that didn't specify a URL, but that's only tips for now.
The listener is passed two arguments: the payload of the result that was picked, and a "details" object whose properties depend on the type of result. For tips, details is `{ helpPicked }`, where `helpPicked` is true if the help button was picked and false if the main button was picked.
Differential Revision: https://phabricator.services.mozilla.com/D46254
--HG--
extra : source : febf4480bc0bce19a0c8883e0c9296c40013e01e
Xiaocheng Hu
Daniel Vogelheim
jgraham
David Major
Bogdan Tara
Jan de Mooij
aardgoose
Coroiu Cristina
Brindusan Cristian
Jan Varga
Martin Thomson
Martin Thomson
Jeff Muizelaar
thomasmo
James Teh
Noemi Erli
Marco Bonardo
Rob Wu
Olli Pettay
Drew Willcoxon
Dorel Luca
alwu
Glenn Watson
Andreea Pavel
Ciure Andrei
Tim Nguyen
Oana Pop Rus
Lee Salzman
Ting-Yu Lin