Also add assertions that enforce that fission requires
DocumentChannel.
Also Removed the use of `rv` from the return statement at the end of
OnStartRequest(nsIRequest.
Differential Revision: https://phabricator.services.mozilla.com/D49101
--HG--
extra : moz-landing-system : lando
the URL moz://a redirects to mozilla's website, Because it redirects to
https we want to use documentchannel.
Depends on D49100
Differential Revision: https://phabricator.services.mozilla.com/D51227
--HG--
extra : moz-landing-system : lando
We cache the path in AnimationInfo for layers, and in
CompsoitorAnimationStorage for web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50013
--HG--
extra : moz-landing-system : lando
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
--HG--
extra : moz-landing-system : lando
We need to pass these two types into the compositor, so we need a better
way to serialize these rust types. We use serde and bincode to
serialize/deserialize them, and use ByteBuf to pass the &[u8] data
through IPC. We define StyleVecU8 for FFI usage only.
Differential Revision: https://phabricator.services.mozilla.com/D50688
--HG--
extra : moz-landing-system : lando
On the compositor thread in GPU process (i.e. web-renderer), gfxPlatform() is
not initialized, so we don't have the DrawTarget information.
Fortunately, all we need is to calculate the motion point and direction
vector, so we don't have to care about which backend we use.
Therefore, make PathBuilder as a parameter, so we can just pass a valid
PathBuilder on the compositor thread. For main thread (i.e. content
process), using the original way is fine.
Differential Revision: https://phabricator.services.mozilla.com/D50010
--HG--
extra : moz-landing-system : lando
The current implementation uses nsIFrame to get everything. However, we
want to reuse ResolveMotionPath() on the compositor thread (in the parent
process), so we need to refactor this function to avoid using nsIframe
everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D50009
--HG--
extra : moz-landing-system : lando
I'd like to add some new data type for motion path, so it'd be great to
put all of them in an independent file.
Differential Revision: https://phabricator.services.mozilla.com/D50008
--HG--
extra : moz-landing-system : lando
This test is setup to run both with and without the pref
"devtools.responsive.browserUI.enabled" set. Ideally, we can find a
way to refactor this structure into something that can be put into
devtools/client/responsive/test/browser/head.js, and other helper
functions in that file can be modified to work with the pref on or
off.
Differential Revision: https://phabricator.services.mozilla.com/D51022
--HG--
extra : moz-landing-system : lando
This is more or less restricted to using `Span::data` and `Span::size` instead
of the equivalent counterparts from `Range`. For example span iterators aren't
used in non-debug code, because the generated code when using span iterators is
ridiculously large.
Differential Revision: https://phabricator.services.mozilla.com/D51122
--HG--
extra : moz-landing-system : lando
Two minor changes for slightly improved generated assembly:
- Use addition/subtraction in AsciiTo[Upper,Lower]Case to ensure the compiler
emits `lea` instead of `mov + bitop`.
- Avoid dead SIMD code generation in LanguageTagSubtag case conversion methods.
Differential Revision: https://phabricator.services.mozilla.com/D51120
--HG--
extra : moz-landing-system : lando
Similar to the previous parts, case normalisation for language, script, and
region subtags now happen as part of the canonicalisation process.
`LanguageTagParser::internalParseBaseName()` no longer needs to differentiate
between parsing a normal base name or a base name within a transform extension,
therefore we can remove its `BaseNameParsing` argument.
The three `ParseStandalone` functions can now use the shared `IsStructurallyValid`
functions, reducing duplicate code.
Subtag canonicalisation in LanguageTagGenerated.cpp now needs to check for case
normalised tags, so some additional assertions were added.
Differential Revision: https://phabricator.services.mozilla.com/D51119
--HG--
extra : moz-landing-system : lando
Moves the case normalisation for variant subtags out of the language tag parser
and into the canonicalisation method. Additionally duplicate variants are now
checked after all variant subtags have been case normalised and sorted, which
makes the duplicate variant check O(n) instead of O(n²). In our implementation
we're always canonicalising language tags directly after parsing them, so
there's no user observable difference when duplicate variants are checked.
Differential Revision: https://phabricator.services.mozilla.com/D51118
--HG--
extra : moz-landing-system : lando
Case normalisation for extension and private-use subtags now happens in `LanguageTag::canonicalizeExtensions`.
The `IsStructurallyValid` functions were updated to only test for structural validity, now finally
matching their name. And `LanguageTagParser::extension(...)` was inlined, because it no longer
also needs to perform case normalisation, which makes it small enough for an inline function.
Differential Revision: https://phabricator.services.mozilla.com/D51117
--HG--
extra : moz-landing-system : lando
`unicodeExtensionIndex()` is already checking for 'U' in preparation for part 2.
Differential Revision: https://phabricator.services.mozilla.com/D51115
--HG--
extra : moz-landing-system : lando
The estimated memory is based on the maximum observed memory usage when running
the Java script attached to the bug report.
Differential Revision: https://phabricator.services.mozilla.com/D51087
--HG--
extra : moz-landing-system : lando
This also updates the canToggle=false code paths in the Picture-in-Picture
mochitest head.js file, which were obviously never really exercised until
now.
Differential Revision: https://phabricator.services.mozilla.com/D51160
--HG--
extra : moz-landing-system : lando
This patch adds GPU and CPU clock frequencies as well as Watts used to the metrics that are gathered into perfherder from mozpower.
Differential Revision: https://phabricator.services.mozilla.com/D50522
--HG--
extra : moz-landing-system : lando
Other places take care to handle this case, but not running the tooltool
script. Let's fix that.
Differential Revision: https://phabricator.services.mozilla.com/D51266
--HG--
extra : moz-landing-system : lando