- Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent
Differential Revision: https://phabricator.services.mozilla.com/D18391
--HG--
extra : moz-landing-system : lando
This is unrelated to this bug (the assertion can already fail without the
patches in this patch queue) but I uncovered it while writing the tests in the
next patch which will trip the assertion that is removed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D19885
--HG--
extra : moz-landing-system : lando
A forthcoming spec change will require that Animatable.animate() and other
methods that mutate animations do not flush style:
https://github.com/w3c/csswg-drafts/issues/3613
Bug 1525809 will add web-platform-tests for this change once it is made (and
tweak the behavior introduced in this patch if necessary).
Currently Firefox and WebKit will flush styles when calling
Animatable.animate(). This is undesirable since this method will _also_
invalidate style. As a result, if content triggers multiple animations in
a single animation frame, it will restyle every time it creates an animation.
This patch removes the style flush from a number of these methods.
In general the style flush is not necessary. For example, we don't need to flush
style before getting the computed style to pass to UpdateProperties. That's
because if there are pending style changes, then UpdateProperties will be called
with the updated style once they are applied anyway. Flushing style first means
that we may end up resolving style twice, when once would be sufficient.
For GetKeyframes() however, when used on a CSS animation, it should return
the most up-to-date style so for that call site we *do* want to flush style.
The test case added in this patch will fail without the code changes in the
patch. Specifically, we will observe 10 non-animation restyles (from the
5 animations) if we flush styles from SetKeyframes.
Differential Revision: https://phabricator.services.mozilla.com/D18916
--HG--
extra : moz-landing-system : lando
test_missing-keyframe-on-compositor.html assumes that calling Element.animate()
will flush style and trigger transitions. However, in this patch series we will
make Element.animate() stop flushing style (and the spec will also mandate
this). Once we do that, the expected transitions will no longer fire and this
test will fail. This patch updates the test to explicitly trigger transitions
before calling Element.animate().
Differential Revision: https://phabricator.services.mozilla.com/D18915
--HG--
extra : moz-landing-system : lando
Without this fix, various tests in
dom/animation/tests/mozilla/test_restyles.html will fail once we remove the
style flush from KeyframeEffect::SetKeyframes. That is because we will fail to
set mCumulativeChangeHint correctly when we initially set up the keyframe's
properties and then never update it since UpdateProperties will return early
when it determines the properties have not changed.
Differential Revision: https://phabricator.services.mozilla.com/D18914
--HG--
extra : moz-landing-system : lando
Typically we set the NS_FRAME_MAY_BE_TRANSFORMED bit on a frame when one of the
following situations arises:
a. We update the keyframes of a KeyframeEffect to include transforms or we
create a new KeyframeEffect that animates transforms (in
KeyframeEffect::SetKeyframes), or
b. We retarget a KeyframeEffect with transforms at a new element (in
KeyframeEffect::SetTarget), or
c. We create an nsFrame with transform animations applied to it (in
nsFrame::Init), or
d. We get a nsChangeHint_AddOrRemoveTransform hint in
RestyleManager::ProcessRestyledFrames and decide to update the frame bit on
the frame and its continuations accordingly.
However, there are some situations where we can have a transform animation on
a frame where none of the above are triggered.
For example, if the style frame is not unavailable (e.g. a display:none
element) when the KeyframeEffect is initialized we will fail to the frame bit in
(a) and if we never retarget the effect we will never set reach (b).
Furthermore, if we have an animation that is "not relevant" (e.g. idle) and
hence not registered with the EffectSet when the frame is initialized we will
fail to set the frame bit in (c).
Finally, if the the animation does not produce a style change that causes the
nsChangeHint_AddOrRemoveTransform bit to be set (e.g. the transform animation
begins at 'none') we will not set the frame bit in (d).
As a result, we can end up failing to set the NS_FRAME_MAY_BE_TRANSFORMED bit
for some content.
The crashtest included in this patch produces such a case and, without the code
changes in this patch, will fail the assertion in ApplyRenderingChangeToTree[1]:
NS_ASSERTION(!(aChange & nsChangeHint_UpdateTransformLayer) ||
aFrame->IsTransformed() ||
aFrame->StyleDisplay()->HasTransformStyle(),
"Unexpected UpdateTransformLayer hint");
That is because although the nsChangeHint_UpdateTransformLayer bit will be set,
aFrame->IsTransformed() will return false because the frame bit has not been
set, and aFrame->StyleDisplay()->HasTransformStyle() will return false because
the animation sets the transform to 'none'.
Not only will this assertion fail, but once we cease flushing style as part of
triggering an animation later in this patch, the reftest
layout/reftests/web-animations/stacking-context-transform-changing-effect.html
will begin to fail. That reftest produces a similar situation to the crashtest
but it currently does not fail because the style flush that happens as part of
creating an animation ensures the style frame is available at the point when the
animation is triggered and hence case (a) from above is hit.
This patch addresses this by detecting the case where we have this change hint
set but not the corresponding frame bit, and setting the frame bit.
[1] https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/layout/base/RestyleManager.cpp#1191-1199
Differential Revision: https://phabricator.services.mozilla.com/D18911
--HG--
extra : moz-landing-system : lando
Regarding the missing dom:: specifications, presumably this currently works
because in the unified build this file gets combined with something with "using
namespace mozilla::dom" but this will fail if the chunking of the unified build
changes.
Differential Revision: https://phabricator.services.mozilla.com/D18910
--HG--
extra : moz-landing-system : lando
Add the origin ContentParent to a CanonicalBrowsingContext's group
when a CanonicalBrowsingContext is created from IPC. With this it is
possible to keep track of all child processes associated with a
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D19004
--HG--
extra : moz-landing-system : lando
The information we'd get would be meaningless anyway in a fully new frame tree
if we don't run layout.
We should consider whether we need to un-suppress whitespace at all here...
Differential Revision: https://phabricator.services.mozilla.com/D19724
--HG--
extra : moz-landing-system : lando
This implements the step of choosing a browsing context with
FindWithName, which should be equivalent to calling
nsIDocShellTreeItem.findItemWithName passing null for 'aRequestor' and
'aOriginalRequestor' and false for 'aSkipTabGroup'.
Differential Revision: https://phabricator.services.mozilla.com/D15190
--HG--
extra : moz-landing-system : lando
The main reason for this change is that we don't really want to share
compartments across same-origin navigations in the same tab (because that will
tend to keep the oldest global involved alive, due to CCWs and
XPCWrappedNatives allocated in that global). We could somehow flag
compartments as not sharable when we navigate, but it's simpler to just switch
zones, since we restrict our search of shareable compartments to a single zone.
A side benefit is that this way the lifetime of objects in a single zone is
more likely to be similar.
Differential Revision: https://phabricator.services.mozilla.com/D19797
--HG--
extra : moz-landing-system : lando
nsClipboardCommand::IsCommandEnabled() accesses document without null-check.
That must be the cause of the reported crash. This patch just adds the check.
Differential Revision: https://phabricator.services.mozilla.com/D19594
--HG--
extra : moz-landing-system : lando
clang-cl defines it on its own, although the value is slightly different
from __FUNCSIG__ (it doesn't contain the ABI, which doesn't really
matter). We've only been setting it this was on clang-cl by extension of
setting it for msvc.
Depends on D19616
Differential Revision: https://phabricator.services.mozilla.com/D19617
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Profiler was previously fetching process name at the time of shutdown
serialization, at which point that name could have already been destroyed.
Now the child process just forwards the name as soon as it is given, so
the profiler can store it for later.
Differential Revision: https://phabricator.services.mozilla.com/D19732
--HG--
extra : moz-landing-system : lando
We support CTAP2 devices on one specific platform, making it hard for RPs to
decide whether or not Firefox will support the tokens they're asking for. This
adds a non-standard method to divine that information while Firefox moves toward
CTAP2 support.
Differential Revision: https://phabricator.services.mozilla.com/D19826
--HG--
extra : moz-landing-system : lando
Move functionality out of XULDocument::AddElementToDocumentPost:
1) Convert all XUL link elements into HTML link elements which have
code to handle when they are added to the DOM.
2) Move handling of the end of a linkset element into nsXULElement's DoneAddingChildren callback.
3) Move document direction reset to where the root element is created.
Differential Revision: https://phabricator.services.mozilla.com/D19739
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
Add a test file that was used to test mp4 parser telemetry to the general suite.
This file was added in the revision before this, and is also useful to provide
further coverage for other tests.
Differential Revision: https://phabricator.services.mozilla.com/D19387
--HG--
extra : moz-landing-system : lando
This is what Chrome does.
documentElement-clientWidth-on-minimum-scale-size.tentative.html was the test
case for this but unfortunately it was disabled in bug 1515043. And it seems
that the test case failed on Android in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D19461
--HG--
extra : moz-landing-system : lando
This is a follow-up to the previous part, which actually changes one of
these callers to use Array<nsIIDRef> instead of [array] nsIIDPtr.
From doing this patch, it seems like we should consider changing
the type `nsIIDRef` to instead simply be `nsIID`, and treat it more like
the `AString` types from the POV of XPIDL. `nsIIDPtr` would then
continue to exist for backwards compatibility, but we can probably
remove almost all current consumers over time.
Depends on D19175
Differential Revision: https://phabricator.services.mozilla.com/D19176
--HG--
extra : moz-landing-system : lando
This patch changes the logic such that we use the new direct
BrowsingContext ParamTraits implementation when possible, and avoids
doing manual lookups.
Depends on D19178
Differential Revision: https://phabricator.services.mozilla.com/D19179
--HG--
extra : moz-landing-system : lando
This patch takes the approach of taking a reference, so that we can land
it into the tree more quickly & fix issues we have.
This isn't a final solution by any means, we should also do something
along the lines of the StableState approach, but it should be sufficient
for now.
Depends on D19177
Differential Revision: https://phabricator.services.mozilla.com/D19178
--HG--
extra : moz-landing-system : lando
Add a gtest to cover the new telemetry probes which collect info on sample
description entries.
Add a new init segment to those already in our gtests. This segment has data for
one video track, and covers the case where multiple sample description entries
are present for a single track. In this case, because separate sample
description entries are used for unencrypted and encrypted samples.
For reference, the test init segment was created from our existing bipbop using
shaka-packager via the following command (non-init segments were discarded and
the output was renamed):
packager-win.exe
in=bipbop.mp4,stream=video,init_segment=bipbop_cbcs_video_init.mp4,segment_template=bipbop_cbcs_video_$Number$.m4s
--protection_scheme cbcs --enable_raw_key_encryption --keys
label=:key_id=7e571d047e571d047e571d047e571d21:key=7e5744447e5744447e5744447e574421
--iv 11223344556677889900112233445566 --generate_static_mpd --mpd_output
bipbop_cbcs.mpd
Depends on D14426
Differential Revision: https://phabricator.services.mozilla.com/D19386
--HG--
extra : moz-landing-system : lando
This patch adds telemetry to help us determine if mp4s with certain structures
can occur in the wild. Specifically:
- How often do mp4s have multiple entries in the sample description box?
- Do we ever see mp4s with multiple codecs in the sample description box?
- Do we ever see mp4s with multiple sets of crypto info in the sample
description box?
This information is collected each time we parse mp4 metadata.
Remove some diagnostic asserts now that we're gracefully gathering info.
Reshuffle of DecoderData function order to align with the order in the header.
Differential Revision: https://phabricator.services.mozilla.com/D14426
--HG--
extra : moz-landing-system : lando
This test is extremely heavy and, often, on android, it timeouts.
Differential Revision: https://phabricator.services.mozilla.com/D19690
--HG--
extra : rebase_source : dc1649720f20af493341a1c5d7b5b23776997707
The mIndexInInserted keeps pointing to the last assigned node of a slot parent
when we are at the end of child list. So when we calles GetPreviousChild when we
are at the end of child list, ExplicitChildIterator will skip last assigned node.
Differential Revision: https://phabricator.services.mozilla.com/D19651
--HG--
extra : moz-landing-system : lando
