Use ResizeObserverController to schedule the observers and manage them.
Document will hold this controller in the later patch.
Depends on D27616
Differential Revision: https://phabricator.services.mozilla.com/D27617
--HG--
extra : moz-landing-system : lando
This implements the first version of spec, so the webidl file doesn't
match the current spec and we will fix them in the follow-up bugs.
i.e.
1. The default observer box is content-box.
2. `ResizeObserverBoxOptions`, `ResizeObserverOptions`, and `ResizeObserverSize`
are not included in `ResizeObserver.webidl`.
3. `ResizeObserverEntry` doesn't have `borderBoxSize` and `contentBoxSize`
attributes.
Depends on D27615
Differential Revision: https://phabricator.services.mozilla.com/D27616
--HG--
extra : moz-landing-system : lando
There's a race condition after initializing an OOP-iframe between the first
paint and when we receive a layers ID for the child browser. If we paint
before getting a layers ID, then the nsDisplayRemote for the subdocument
will not reference the child browser. Then when the child browser paints,
it will never be linked in the final layer tree/display list.
This patch triggers an invalidation of the subdocument frame when we
get the layers ID for the OOP-iframe to prevent this.
Differential Revision: https://phabricator.services.mozilla.com/D29024
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
This patch updates BUG_COMPONENT for some dom/* and testing/web-platform/* files
Differential Revision: https://phabricator.services.mozilla.com/D28721
--HG--
extra : moz-landing-system : lando
***
Removed IPC References in PCContent
***
Removed IPC References on nsContentPermissionHelper
***
Remove IPC Principal from PBrowser
***
Remove IPCPrincipal from the PaymentRequest
***
Remove IPCPrincipal from the PPresentation
***
Remove IPC Principal from PNecko
Differential Revision: https://phabricator.services.mozilla.com/D28650
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
We have a better type to represent "a coord or nothing", and that's Maybe.
This code is shorter, and I think reads generally better / is less easy to
misuse.
I wrote this on top of bug 1547126 so there shouldn't be conflicts.
Differential Revision: https://phabricator.services.mozilla.com/D28921
--HG--
extra : moz-landing-system : lando
Use ResizeObserverController to schedule the observers and manage them.
Document will hold this controller in the later patch.
Depends on D27616
Differential Revision: https://phabricator.services.mozilla.com/D27617
--HG--
extra : moz-landing-system : lando
This implements the first version of spec, so the webidl file doesn't
match the current spec and we will fix them in the follow-up bugs.
i.e.
1. The default observer box is content-box.
2. `ResizeObserverBoxOptions`, `ResizeObserverOptions`, and `ResizeObserverSize`
are not included in `ResizeObserver.webidl`.
3. `ResizeObserverEntry` doesn't have `borderBoxSize` and `contentBoxSize`
attributes.
Depends on D27615
Differential Revision: https://phabricator.services.mozilla.com/D27616
--HG--
extra : moz-landing-system : lando
We're rarely getting nullptrs out of MediaQueues. It's not clear where these are
coming from, as we have many guards against them. Upgrade this assert to a
diagnostic to help us track the source and determine if the value is null before
entering the queue.
Differential Revision: https://phabricator.services.mozilla.com/D28866
--HG--
extra : moz-landing-system : lando
We don't currently know any ways in which external code can make the
suspendCount negative, but this will keep us safe should a future bug enable it.
Depends on D28805
Differential Revision: https://phabricator.services.mozilla.com/D28806
--HG--
extra : moz-landing-system : lando
the requestSecurityCode allows merchants to opt out of requiring a CVV from a credit card.
Differential Revision: https://phabricator.services.mozilla.com/D28777
--HG--
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
This patch creates new header, `mozilla/PresShellForwards.h`. It should have
all forward declarations of global class/struct in `nsIPresShell.h` and
`mozilla/PresShell.h`.
Additionally, this moves all `enum`s and `constant`s in them into the new file
with changing them to `enum class`es.
This will make other headers which require only specific types in the header
files not include them.
Differential Revision: https://phabricator.services.mozilla.com/D28605
--HG--
extra : moz-landing-system : lando
We assume in a bunch of other places that user agent stylesheets don't really
change dynamically. It's not clear to me what this code is trying to accomplish
or how is it supposed to work in a multi-process world, but I've left the author
stylesheets code for now...
Also, I'm pretty sure the styleset doesn't handle null sheets, so add a
null-check to the author stylesheets.
Differential Revision: https://phabricator.services.mozilla.com/D28211
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
The value of `mAudioDecodedDuration` can be larger than `int32`, so we should use the modular function which accepts `TimeUnit`as a input.
Differential Revision: https://phabricator.services.mozilla.com/D28536
--HG--
extra : moz-landing-system : lando
We should only use valid time to construct a `SeekTarget`, because we can't get the value from the invalid time.
This can help us to prevent having a crash when request data value from an invalid time.
Differential Revision: https://phabricator.services.mozilla.com/D28564
--HG--
extra : moz-landing-system : lando
As the purpose of adjusting time is to make the start of the playback to align to zero, so the result should not be negative.
Differential Revision: https://phabricator.services.mozilla.com/D28432
--HG--
extra : moz-landing-system : lando
Considering that the audio sample's time is always increased, the decoded sample's time decoder returns should always be equal or larger than its demuxed time.
When the decoded sample's time is smaller than the time of first demuxed sample, that time would probably cause a problem so we should throw an error for that.
Differential Revision: https://phabricator.services.mozilla.com/D28167
--HG--
extra : moz-landing-system : lando
This moves the responsibility for creating MediaStreamTracks from
DecodedStream::Start to MediaDecoder. This let's MediaDecoder create them as
soon as metadata is known. This gives the application guarantees on when tracks
can be expected to exist, and aligns with the spec that says they should be
created when metadata is known.
Differential Revision: https://phabricator.services.mozilla.com/D28473
--HG--
extra : moz-landing-system : lando
This gives us a guarantee that the first frame of a media file can be rendered
with a second media element and mozCaptureStream(), even if the file is very
very short.
With longer video-only files there were also cases where nothing ended up being
rendered. Probably because the MediaStreamGraph ended up switching from an
AudioCallbackDriver to a SystemClockDriver and this took enough time to put the
SourceMediaStream::EndTrack and the SourceMediaStream::AddTrackListener calls
for this video track to be processed in the same iteration. The listener would
then always lose to the ending track and update main thread state too late,
leading to its media element not rendering any frames and nasty intermittent
failures.
Differential Revision: https://phabricator.services.mozilla.com/D27270
--HG--
extra : moz-landing-system : lando
`streamCurrentTime` is relative to the start of the stream, as is the track's
segment. We need to account for the track's start time in the stream when
notifying of output.
Differential Revision: https://phabricator.services.mozilla.com/D27268
--HG--
extra : moz-landing-system : lando
A case where this wasn't working was bipbop-lateaudio.mp4, where the last frame
has duration 0 and starts and ends before the previous frame has ended. The
VideoSink still renders this frame at the end of playback, so this patch
brings DecodedStream closer to that behavior by rendering all frames with a
start time after the previous frame's start time. The track's duration is still
based on absolute times so things don't blow up.
Differential Revision: https://phabricator.services.mozilla.com/D27267
--HG--
extra : moz-landing-system : lando
This is necessary to get an accurate total track duration in case DecodedStream
does a lot of seeking and pausing.
This also removes previous code for avoiding blocking a video track, as this new
code handles that case too.
Differential Revision: https://phabricator.services.mozilla.com/D27264
--HG--
extra : moz-landing-system : lando
Null frames could still be valid. It's how DecodedStream signals a pause. They
could also be valid and have an intrinsic size and the force-black flag set.
Differential Revision: https://phabricator.services.mozilla.com/D27263
--HG--
extra : moz-landing-system : lando
This is similar to what VideoSink does, and is required for us to end playback
on HAVE_CURRENT_DATA (a frame for currentTime must be available).
Differential Revision: https://phabricator.services.mozilla.com/D27261
--HG--
extra : moz-landing-system : lando
This tests HTMLMediaElement::MozCaptureStream on all of our play-tests, rather
than just a single test, in order to test more corner cases in the capture code.
Because this test checks that the media element that's playing the
mozCaptureStream()-stream ends after at least the duration of the original media
file, and because media elements playing a MediaStream have a `currentTime`
based on the MediaStreamGraph's monotonically increasing clock, we need to have
accurate metadata for how long the duration of the content of the original media
file is. There are several cases among the play-tests where the duration
metadata doesn't match what the decoder gives us -- the reason is often preroll
or corrupt containers. This patch updates manifest.js with `contentDuration` for
the tests among `gPlayTests` where try detected mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D27257
--HG--
extra : moz-landing-system : lando
1. Propagate the mListener's result in InterceptedHttpChannel::OnStartRequest()
and ::OnStopRequest().
2. remove unnecessary assertion in FetchDriver::OnStartRequest().
Differential Revision: https://phabricator.services.mozilla.com/D28477
--HG--
extra : moz-landing-system : lando
When we suspend or resume the `AudioContext`, it should affect ALL media streams which belong to or are related to the `AudioNode` that are created by this `AudioContext`.
As `AudioNode::OutputParams()` can only return the connected AudioParams, it doesn't return the AudioParams which are belong to itself. That means we would miss to apply the suspend/resume operation for those streams, and it would cause imbalancing suspended count.
Therefore, we let `AudioNode` to keep the reference of all its AudioParam, and return them to `AudioContext` in order to do the operation for all streams.
Differential Revision: https://phabricator.services.mozilla.com/D28008
--HG--
extra : moz-landing-system : lando
Create a new IPDL message `ShutdownComplete`, direction from parent (RDD) to child (content), to inform the child when the decoder shutdown has been completed. The remote decoder child uses that message to resolve the shutdown promise.
Differential Revision: https://phabricator.services.mozilla.com/D28340
--HG--
extra : moz-landing-system : lando
This adds a single new method, which acts like sendAsyncMessage, but
also returns a promise. This promise is fulfilled when the promise
returned from the receiveMessage callback is resolved.
```
partial interface JSWindowActor {
[Throws]
Promise<any> sendQuery(DOMString messageName,
optional any obj,
optional any transfers);
}
```
Differential Revision: https://phabricator.services.mozilla.com/D27809
--HG--
extra : moz-landing-system : lando
We should not treat <iframe> as <object> for SVG, otherwise there will
be unexpected sizing and other webcompat problem (e.g. getScreenCTM).
It behaved correctly before, the change was introduced to solve a double
zooming problem (bug 843480) for <iframe>. Actually the zooming problem
can be solved by avoiding zooming when the window frame is an <iframe>.
Differential Revision: https://phabricator.services.mozilla.com/D28313
--HG--
extra : moz-landing-system : lando
This patch marks `ScrollContentIntoView()` as `MOZ_CAN_RUN_SCRIPT` and changing
some callers of them to guarantee thar their parent callers are also safe.
Additionally, this patch moves it from `nsIPresShell` to `PresShell` because
all callers can refer `PresShell` directly.
Unfortunately, this patch changes a lot of methods in autocomplete and satchel
since this patch needs to mark some interface methods as `can_run_script` and
they are called each other. This means that autocomplete module is really
sensitive like editor module. Perhaps, autocomplete and satchel should do
scroll asynchronously and unmark some of them as `MOZ_CAN_RUN_SCRIPT` again.
Differential Revision: https://phabricator.services.mozilla.com/D28320
--HG--
extra : moz-landing-system : lando
Next, we should mark `PresShell::ScrollContentIntoView()` as
`MOZ_CAN_RUN_SCRIPT` because it's used widely.
This patch marks its `PresShell` users, `GoToAnchor()` and `ScrollToAnchor()`,
as `MOZ_CAN_RUN_SCRIPT`. Additionally, this patch moves them from
`nsIPresShell` to `PresShell` because all callers refers `PresShell` directly.
Differential Revision: https://phabricator.services.mozilla.com/D28319
--HG--
extra : moz-landing-system : lando
Changes:
- added comments for tests being disabled
- disabled two additional tests in order to green the run
Differential Revision: https://phabricator.services.mozilla.com/D28085
--HG--
extra : moz-landing-system : lando
Most wrapper cached C++ objects are held alive by their wrapper. The
cycle collector takes advantage of this in many classes and ignores
the C++ object if the wrapper is marked black.
However, this is not true for the outer window's wrapper. Instead, the
outer window's wrapper keeps the inner window alive. The inner window
usually keeps its outer window alive, but not after it has been
unlinked. For reasons I do not yet understand, the outer window's
wrapper can be kept alive after the inner window it is a proxy for is
unlinked.
This patch fixes the cycle collector optimization for the outer window
by only applying it if the outer window still has a weak reference to
the inner window, which it will until the inner no longer holds the
outer alive. This in turn fixes, or at least helps fix, window leaks
seen intermittently when the lifetime of outer windows and docshells
are tied together.
The code comment is based on a review comment by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D27981
--HG--
extra : moz-landing-system : lando
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::region to WidgetMouseEventBase::mRegion
Differential Revision: https://phabricator.services.mozilla.com/D25323
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::hitCluster to WidgetMouseEventBase::mHitCluster
Differential Revision: https://phabricator.services.mozilla.com/D25318
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::pressure to WidgetMouseEventBase::mPressure
Differential Revision: https://phabricator.services.mozilla.com/D25314
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
The attributes for an interface should be on the line right before the
interface.
Interface attributes should be separated by spaces.
Clean up some trailing whitespace in widget/.
Differential Revision: https://phabricator.services.mozilla.com/D28234
--HG--
extra : moz-landing-system : lando
Key::ToLocaleBasedKey() overlooked the existence of |eBinary| type,
probably because |eBinary| was added later and the code wasn't updated
properly.
Differential Revision: https://phabricator.services.mozilla.com/D24882
--HG--
extra : moz-landing-system : lando
If the RDD process is enabled and fails to start properly for some reason,
make sure we cannot accidentally fall back to decoding AV1 on the content
process.
Differential Revision: https://phabricator.services.mozilla.com/D28204
--HG--
extra : moz-landing-system : lando
When an imageloadingcontent is moved between documents, nsNodeUtils::CloneAndAdopt looks for it as an element in the list of activity observers, and so it doesn't find it to remove and add to the new doc.
Differential Revision: https://phabricator.services.mozilla.com/D28002
--HG--
extra : moz-landing-system : lando
As operator`%` would need to handle `TimeUnit` as a input as well, we add new operator function.
Also use `int64` as a input parameter for another two operator functions `%` and `/` in order to add assertion to ensure that the input won't overflow.
Differential Revision: https://phabricator.services.mozilla.com/D27644
--HG--
extra : moz-landing-system : lando
This patch adds an ID to ensure that we avoid canceling content JS if the next
page already started loading by the time we're ready to try canceling the JS.
Differential Revision: https://phabricator.services.mozilla.com/D25164
--HG--
extra : moz-landing-system : lando
In this part, we pass along the navigation type (and index for when using the
dropdown on the back/forward buttons). This allows us to check if there's a
top-level load "between" the start and end pages.
The patch might look a bit strange, since we're passing the navigation
operation to two places from RemoteWebNavigation.js (the normal message passing
that existed before this patch and the HangMonitor channel in this patch). This
is primarily to make it easier to stop passing the navigation info along the
HangMonitor channel once session history is uplifted into the parent process.
At that point, the check for whether there's a top-level load could happen in
TabParent (I think).
Differential Revision: https://phabricator.services.mozilla.com/D23090
--HG--
extra : moz-landing-system : lando
This patch passes a message through the HangMonitor channel when navigating
through history to cancel content JS that could hang the chrome JS in the
content process responsible for history navigation. If the content JS is
actually canceled, this also disables the BF cache for the current page, since
it could end up in an inconsistent state due to the JS cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D23089
--HG--
extra : moz-landing-system : lando
The real problem is because the connection was closed for some reason. This
patch won't resolve the issue by only let the operation and the transaction fail
to escape from the crash. Note that it also changing an assertion when the
transaction is either commiting or aborting. This is prevent the problem for
closing connection is worser than we expected.
Differential Revision: https://phabricator.services.mozilla.com/D28148
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
CloseAudioInut method posts a message, to the graph thread, in order to close the input asynchonously. When CloseAudioInput method was being executed from a thread other than the main thread, a runnable would be posted to main thread in order to post the async message from there. That was a risky path because when the graph was shutting down there were no guarantee that the close-input message would reach the graph thread before destroy takes place. By limiting CloseAudioInput to main thread it is ensured that the close-input message will be executed before destroy.
Differential Revision: https://phabricator.services.mozilla.com/D27751
--HG--
extra : moz-landing-system : lando
Revive method of AudioCallbackDriver was wrong because it was re-initializing an already initialized driver. That was hitting an assert. Instead of that it should stop the drained stream and start it again. Also, mStarted member should be reset properly on the stop method.
Differential Revision: https://phabricator.services.mozilla.com/D26678
--HG--
extra : moz-landing-system : lando
As of this change, instances of xul <button> use a custom element.
The button-base xbl binding remains for now, since it is still used
by toolbarbutton, it will be removed soon.
Differential Revision: https://phabricator.services.mozilla.com/D27742
--HG--
rename : toolkit/content/widgets/button.xml => toolkit/content/widgets/button.js
extra : rebase_source : 2be8ee3fa9bb43866013f62211d8cb3706dbf1ab
This should keep memory usage a bit more under control when loosing a pres
shell.
Differential Revision: https://phabricator.services.mozilla.com/D27571
--HG--
extra : moz-landing-system : lando
Just one set of stylesheets is enough. While at it, unify SheetType and Origin.
Differential Revision: https://phabricator.services.mozilla.com/D27564
--HG--
extra : moz-landing-system : lando
If needed for web-compat.
Also stop dispatching auxclicks if non-primary click has been preventDefaulted,
so that legacy new-tab prevention can work with the pref flip.
Differential Revision: https://phabricator.services.mozilla.com/D27364
--HG--
extra : moz-landing-system : lando
It's against spec, and the auxclick event is now available and easier to use
(fired on all elements rather than just window/document and text fields)
Can't stop dispatching them entirely since frontend code is too reliant on it.
Don't fire dblclick for auxclick.
Mark wpt uievents/click/auxclick_event.html as passing
Update test_clipboard_events.html
Differential Revision: https://phabricator.services.mozilla.com/D26793
--HG--
extra : moz-landing-system : lando
Editable elements will no longer get click events for non-primary mouse buttons
since they are being unshipped from the web in favour of auxclick events.
Listen for auxclick as well so middle-click paste still works.
Don't stop propagation after middle-click paste, instead ignore clicks on
contenteditable elements in ClickHandlerChild.
Update test_middle_click_paste.html for the new behaviour.
Also remove the mNoContentDispatch overrides in HTMLInputElement and
HTMLTextAreaElement that were needed for middle-pasting.
Differential Revision: https://phabricator.services.mozilla.com/D26792
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
Shutting down the taskqueue early prevents the decoder's tasks to be queued.
A TaskQueue no longer requires to be explicitly shutdown it will shutdown when ref counter drops to zero.
Differential Revision: https://phabricator.services.mozilla.com/D26929
--HG--
extra : moz-landing-system : lando
It's a bit useless, only has one implementation. Call into the shell directly
instead.
Differential Revision: https://phabricator.services.mozilla.com/D27910
--HG--
extra : moz-landing-system : lando
See the previous patch in this series for a detailed explanation of why this is
necessary.
The test included in this patch is from some work I am doing to rewrite the CSS
transitions web-platform-tests. As a result, it includes more than is strictly
related to this issue addressed by this bug. Without the code changes in this
patch the fourth test onwards, "Transitions are canceled when an element is
removed from the document", will timeout waiting for the transitioncancel event.
Differential Revision: https://phabricator.services.mozilla.com/D28022
--HG--
extra : moz-landing-system : lando
Currently we avoid posting animation restyles when unbinding an element by
removing the element from the document before deleting its animation
collections. As a result, when canceled animations go to post a restyle, they
can't find a pres context and give up posting a restyle.
However, this is problematic for two reasons:
* It means we can't remove such canceled animations from the
PendingAnimationTracker if they are present there (i.e. it regresses the fix
from bug 1223445).
* It means we can't post cancel events for such animations/transitions since we
can't lookup the appropriate AnimationEventDispatcher.
In the next patch in this series we will change that order to fix the above
problems but before we do that, we need to introduce another mechanism to make
sure that we don't post restyles when unbinding an element or else we will
regress bug 1396041.
This patch does that by introducing a flag which causes us to not post restyles
when we are doing DOM surgery. For all other cases we actually _do_ need to post
restyles in order to update the style correctly.
Without this patch, layout/style/crashtests/1396041.html would fail after
applying the next patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D28021
--HG--
extra : moz-landing-system : lando
Animation::Cancel calls UpdateTiming() which in turns runs the procedure to
update the finished state. However, the spec[1] doesn't require that.
Furthermore, calling UpdateTiming here hides the fact that we end up triggering
a restyle.
It would be better to move the parts of UpdateTiming we require into Cancel
itself so that we align better with the spec and to make it a bit more clear
what side-effects of UpdateTiming we actually rely on.
[1] https://drafts.csswg.org/web-animations-1/#cancel-an-animation
Differential Revision: https://phabricator.services.mozilla.com/D28020
--HG--
extra : moz-landing-system : lando
CancelNoUpdate actually can and does trigger restyles via its call to
KeyframeEffect::NotifyAnimationTimingUpdated so at very least its name is wrong.
Furthermore, we actually want canceling to trigger restyles in most cases since
when an animation is canceled we need to trigger a subsequent restyle to apply
the (no-longer-animated) result.
This wasn't necessary when CancelNoUpdate was first introduced but since then we
have introduced the Servo style engine where we use a separate traversal to
apply the result from creating/deleting/modifying animations.
This change will mean that we now trigger a "layer" restyle when canceling an
animation when we previously didn't. That, however, seems more correct if
anything.
This patch also makes CancelFromStyle no longer virtual since it doesn't seem
necessary anymore (perhaps because we now point to the concrete type:
CSSAnimation/CSSTransition from nsAnimationManager/nsTransitionManager whereas
previously we didn't).
Differential Revision: https://phabricator.services.mozilla.com/D28019
--HG--
extra : moz-landing-system : lando
Changes:
- most tests are skipped using `moz.build` configuration file.
- `MultiWriterQueue` had to be skipped with `define` clauses in the test file due to build bustages when its `moz.build` file was used.
Differential Revision: https://phabricator.services.mozilla.com/D27944
--HG--
extra : moz-landing-system : lando
It just does wasted work. The new setup is also much more similar to the one
used for element states.
Differential Revision: https://phabricator.services.mozilla.com/D27905
--HG--
extra : moz-landing-system : lando
This gives us a guarantee that the first frame of a media file can be rendered
with a second media element and mozCaptureStream(), even if the file is very
very short.
With longer video-only files there were also cases where nothing ended up being
rendered. Probably because the MediaStreamGraph ended up switching from an
AudioCallbackDriver to a SystemClockDriver and this took enough time to put the
SourceMediaStream::EndTrack and the SourceMediaStream::AddTrackListener calls
for this video track to be processed in the same iteration. The listener would
then always lose to the ending track and update main thread state too late,
leading to its media element not rendering any frames and nasty intermittent
failures.
Differential Revision: https://phabricator.services.mozilla.com/D27270
--HG--
extra : moz-landing-system : lando
`streamCurrentTime` is relative to the start of the stream, as is the track's
segment. We need to account for the track's start time in the stream when
notifying of output.
Differential Revision: https://phabricator.services.mozilla.com/D27268
--HG--
extra : moz-landing-system : lando
A case where this wasn't working was bipbop-lateaudio.mp4, where the last frame
has duration 0 and starts and ends before the previous frame has ended. The
VideoSink still renders this frame at the end of playback, so this patch
brings DecodedStream closer to that behavior by rendering all frames with a
start time after the previous frame's start time. The track's duration is still
based on absolute times so things don't blow up.
Differential Revision: https://phabricator.services.mozilla.com/D27267
--HG--
extra : moz-landing-system : lando
This is necessary to get an accurate total track duration in case DecodedStream
does a lot of seeking and pausing.
This also removes previous code for avoiding blocking a video track, as this new
code handles that case too.
Differential Revision: https://phabricator.services.mozilla.com/D27264
--HG--
extra : moz-landing-system : lando
Null frames could still be valid. It's how DecodedStream signals a pause. They
could also be valid and have an intrinsic size and the force-black flag set.
Differential Revision: https://phabricator.services.mozilla.com/D27263
--HG--
extra : moz-landing-system : lando
This is similar to what VideoSink does, and is required for us to end playback
on HAVE_CURRENT_DATA (a frame for currentTime must be available).
Differential Revision: https://phabricator.services.mozilla.com/D27261
--HG--
extra : moz-landing-system : lando
This tests HTMLMediaElement::MozCaptureStream on all of our play-tests, rather
than just a single test, in order to test more corner cases in the capture code.
Because this test checks that the media element that's playing the
mozCaptureStream()-stream ends after at least the duration of the original media
file, and because media elements playing a MediaStream have a `currentTime`
based on the MediaStreamGraph's monotonically increasing clock, we need to have
accurate metadata for how long the duration of the content of the original media
file is. There are several cases among the play-tests where the duration
metadata doesn't match what the decoder gives us -- the reason is often preroll
or corrupt containers. This patch updates manifest.js with `contentDuration` for
the tests among `gPlayTests` where try detected mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D27257
--HG--
extra : moz-landing-system : lando
Don't assume XPCOM_MEM_BLOAT_LOG is a filename. XPCOM_MEM_BLOAT_LOG and XPCOM_MEM_LEAK_LOG can be set to a filename or "1" or "2" for logging to stdout and stderr respectively.
Set the debug write directory for XPCOM_MEM_LEAK_LOG in the same way we already to for XPCOM_MEM_BLOAT_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D27968
--HG--
extra : moz-landing-system : lando
This line appears to be perma-failing right now in `Android 7.0 x86-64
opt : M[tier-2](2)`. This seems to be being caused by the PContent's
channel being closed during shutdown also causing TabParents to be shut
down too late, after the document which they're embedded in has started
dying(?)
This patch just does the "obvious" thing of adding a null check (due to
it looking like a null dereference).
Differential Revision: https://phabricator.services.mozilla.com/D27947
--HG--
extra : moz-landing-system : lando
- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando