In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
This one I'm not 100% sure about whether we want to keep special-casing shadow
DOM.
Seems we may want to, but on the other hand this looks like a hack (as it only
looks at the closest shadow host, not the whole chain, and it is green on try).
Depends on D53200
Differential Revision: https://phabricator.services.mozilla.com/D53201
--HG--
extra : moz-landing-system : lando
Wants to check that the change happens in the same anon tree, use the right
function for that.
Depends on D53199
Differential Revision: https://phabricator.services.mozilla.com/D53200
--HG--
extra : moz-landing-system : lando
Shadow DOM is handled above.
And do some minor drive-by cleanups. Unclear why we have both this and the
RangeUtils version.
Depends on D53194
Differential Revision: https://phabricator.services.mozilla.com/D53195
--HG--
extra : moz-landing-system : lando
They want to check that the root is correct, do so explicitly.
Depends on D53197
Differential Revision: https://phabricator.services.mozilla.com/D53198
--HG--
extra : moz-landing-system : lando
And make ShadowRoot.contains() and checking nodes from different shadow trees
faster.
Differential Revision: https://phabricator.services.mozilla.com/D53037
--HG--
extra : moz-landing-system : lando
We were already relying on reinterpret_cast so it seems ok and will make the
code in following patches a bit nicer.
Differential Revision: https://phabricator.services.mozilla.com/D53028
--HG--
extra : moz-landing-system : lando
We don't need the full generality of templated typed arrays here, just
the ability to assign from `Uint8Array`. Some versions of clang in
C++17 mode have problems with overload resolution when faced with
templated method parameters that resolve to base classes of the passed
arguments. Using the more-specific type here avoids those bugs.
Differential Revision: https://phabricator.services.mozilla.com/D53069
--HG--
extra : moz-landing-system : lando
We always fall through if !IsInNativeAnonymousContent(), as
GetAnonRootIfInAnonymousContentContainer will return null.
Differential Revision: https://phabricator.services.mozilla.com/D53031
--HG--
extra : moz-landing-system : lando
We don't have any NAC which is a <xul:label>. We could keep it for shadow dom but it
doesn't seem to me like this code is working correctly.
nsXULLabelFrame::RegUnregAccessKey doesn't have similar code, and uses the
<label> node to register / unregister.
Finally, we do have non-anon labels, and those would be broken... So just
remove the special-case.
Depends on D53058
Differential Revision: https://phabricator.services.mozilla.com/D53059
--HG--
extra : moz-landing-system : lando
This is technically a behavior change, but the current thing is more correct
anyways, IMO, and it's only a warning in any case.
Differential Revision: https://phabricator.services.mozilla.com/D53058
--HG--
extra : moz-landing-system : lando
This doesn't need to handle NAC anymore since <svg:use> element doesn't use NAC
anymore.
Handle Shadow DOM by using GetParentOrShadowHostNode(), though we should figure
out what the right thing to do since GetOwnerSVGElement and co. use
GetFlattenedTreeParent().
In practice, these should be equivalent because SVG Elements can't be shadow
hosts.
Differential Revision: https://phabricator.services.mozilla.com/D53063
--HG--
extra : moz-landing-system : lando
Now that XBL is gone, the only anonymous subtrees are NAC.
I'd prefer to defer the removal of IsInAnonymousSubtree if possible, as there's
a bunch of patches coming on top of this one :)
Differential Revision: https://phabricator.services.mozilla.com/D53033
--HG--
extra : moz-landing-system : lando
- Add a pref for controlling the batch size when doing webaudio decoding
on RDD.
- If batch size is greater than 1 and the decoder is capable of batch
decoding, send raw sample batches to decoder.
Differential Revision: https://phabricator.services.mozilla.com/D51454
--HG--
extra : moz-landing-system : lando
Stop using MediaFormatReader and use a demuxer and decoder directly in
MediaBufferDecoder. This will allow us to do batch decoding calls for
webaudio that will improve performance by reducing the number of IPC
calls to the RDD process.
Differential Revision: https://phabricator.services.mozilla.com/D51453
--HG--
extra : moz-landing-system : lando
In order to use the batch decoding abilities added in Bug 1590475,
we need to also add batch decoding to MediaDataDecoder. For now
only RemoteMediaDataDecoder (and AudioTrimmer as a wrapper) know
how to do batch, but this could be implemented more generically
later in MediaDataDecoder.
Differential Revision: https://phabricator.services.mozilla.com/D51452
--HG--
extra : moz-landing-system : lando
CreateDemuxer will be used in MediaBufferDecoder as we remove MediaFormatReader.
Differential Revision: https://phabricator.services.mozilla.com/D45094
--HG--
extra : moz-landing-system : lando
The launcher process turns on the `PreferSystem32Images` mitigation policy for
the browser process. Since the mitigation policy is inherited, a process launched
by the browser process also has `PreferSystem32Images`. If an application which
does not support `PreferSystem32Images`, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.
Bug 1567614 fixed this issue by introducing `mozilla::ShellExecuteByExplorer` to
`nsMIMEInfoWin::LoadUriInternal`. This patch introduces
`mozilla::ShellExecuteByExplorer` to two more places.
1. xul!nsLocalFile::Launch
This is invoked when a user opens a file from the Download Library, or a user
opens a downloaded file with the default application without saving it.
2. xul!nsMIMEInfoWin::LaunchWithFile
This is invoked when a user opens a downloaded file with a custom application
(configured in about:preference) without saving it.
*Why does this patch change worker.js?*
The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch. This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.
The test browser_download.js can verify downloaded data without opening an
associated application. So this patch adds the content-type to the response
header in order not to open Notepad on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D52567
--HG--
extra : moz-landing-system : lando
The event source in `MediaControlKeysManager` now is created dynamically, so that means sometime we don't have an event source to allow people add or remove listener
Therefore, make `MediaControlKeysManager` inherit from `MediaControlKeysEventSource` to allow it to provide add/remove listener methods and inherit from `MediaControlKeysEventListener` to allow it to monitor the real media control keys event and dispatch event to its listeners.
Differential Revision: https://phabricator.services.mozilla.com/D51766
--HG--
extra : moz-landing-system : lando
Use` nsISupport` for ref counting, instead of using `NS_INLINE_DECL_THREADSAFE_REFCOUNTING`, then we can allow an usage such like inheritting from both `MediaControlKeysEventListener` and `MediaControlKeysEventSource` at the same time, which doesn't be allowed in old implementation because we can only have one parent class owning `mRefCnt`.
Differential Revision: https://phabricator.services.mozilla.com/D52703
--HG--
extra : moz-landing-system : lando
In this patch, we dynamically create or destroy media keys event source according to the amount of media controller .
We would create the event source when we have a controller which needs to be controlled, and destory the event source when there is no controllers existing.
In addition, create a `Init()` function for media service for calling any other owned module's initialization, which is used to ensure that we finish setting the `gMediaControlService` before any other classes call `MediaControlService::GetService()`.
Differential Revision: https://phabricator.services.mozilla.com/D51765
--HG--
extra : moz-landing-system : lando
As we have a need to know if there is any existing controller needs to be controlled in order to achieve dynamically creation and destruction of media keys event source. (that will be implemented in patch2)
Therefore, using the media event to send the current media controller amount when the total media controller amount changed in the media service.
Differential Revision: https://phabricator.services.mozilla.com/D51763
--HG--
extra : moz-landing-system : lando
TreeWalker could use some similar changes, but that is a different bug. TreeWalker does use TestNode method too, which is why
the new argument is optional. A new bug will be filed for TreeWalker.
Differential Revision: https://phabricator.services.mozilla.com/D53016
--HG--
extra : moz-landing-system : lando