The Java ExoPlayer that we use for HLS support on Android does an accurate
seek, that is, it seeks to the frame at the seek target. This may not be a
keyframe, which we can start decoding at. So change the HLS seek to seek 2
seconds behind the seek target, and drop all frames up to the next keyframe.
This means that after a seek the HLSDemuxer will output a keyframe, and
hopefully (but we can't guarantee of course) it will lie behind the actual seek
target.
We also need to purge the GeckoHlsVideoRenderer's queue of frames which it
is holding onto in order to determine their durations, otherwise after a seek,
we'll get output from this queue of frames. That is, after a seek we would still
get a few frames from the old playback position.
This seek case is particularly problematic as we aggressively shutdown decoders
when the media is paused, including right after the load reaches
loadedmetadata, and we need to seek in order to recover from going dormant.
Differential Revision: https://phabricator.services.mozilla.com/D33254
--HG--
extra : moz-landing-system : lando
This patch makes several changes to the kinds of URLs where we can cancel
content JS when navigating between them:
1) When navigating directly to a URL (e.g. by typing something into the
location bar and hitting Enter), we allow canceling content JS if the URLs
differ in any way *except* their ref ("#"). To help with this, we also
attempt to fix up the URL (e.g. by prepending "http://" to it).
2) When navigating through history, we allow canceling content JS if the
`prePath` part of the URLs differ. Most notably, this allows canceling
content JS when one of the URLs is an `about:` page (e.g. when hitting the
Home button).
3) We explicitly disallow cancelling content JS if the currently-running JS
is trusted or if the page being navigated away from is anything but
http(s): or file:.
4) We also disallow cancelling content JS for windows that are still being
created (e.g. when creating a new tab or window via `window.open`). For
more background on this, see the comments about `mCreatingWindow` in
dom/ipc/BrowserParent.h.
5) We ensure that, when attempting to cancel JS, the tab ID of the
currently-running script matches the original tab that requested the
cancellation. This avoids a race condition in which a particular JSContext
has already moved on to executing another tab's JS by the time we hit our
interrupt callback.
Differential Revision: https://phabricator.services.mozilla.com/D31875
--HG--
extra : moz-landing-system : lando
LS Request parameters are now verified as part of the state machine so an actor
is always created. Before this patch, we were doing verification prior to actor
creation. If the verification failed, we didn't create an actor and content
was endlessly waiting for a reply.
Normally, this method will return the entire in string if it has a scheme.
However, mParser->ParseURL may fail, leading to the scheme to be cleared,
and the result will be the same HTTP URL with the input appended to the
path. This triggers the assertion in NS_NewURI that the scheme should not
change.
As a fix, we bail out of nsStandardURL::Resolve() if the parsed scheme of
the input is different than the base URIs current scheme. This condition
is necessary, because we still need to support a deprecated form of relative
URLs like http:file or http:/path/file
Differential Revision: https://phabricator.services.mozilla.com/D33003
--HG--
extra : moz-landing-system : lando
Named constructors are eInterface but are plain Function objects, without a
DOMIfaceAndProtoJSClass class.
Differential Revision: https://phabricator.services.mozilla.com/D32941
--HG--
extra : moz-landing-system : lando
`HTMLEditor` initializes selection ancestor limit when it receives `focus`
event. If `Document.execCommand()` is called immediately after an
ancestor of active editing host becomes new editing host,
`HTMLEditor::GetActiveEditingHost()` returns the new one, but selection
ancestor limit is still the previous one. This mismatch causes a lot of
bugs. Therefore, this patch makes `nsGenericHTMLElement` notifies `HTMLEditor`
of an element becoming `contenteditable`, and makes `HTMLEditor` update
selection ancestor limit only when the new editing host is ancestor of
old selection ancestor limit.
Differential Revision: https://phabricator.services.mozilla.com/D32823
--HG--
extra : moz-landing-system : lando
If window emulation is enabled, an out-of-process iframe document should use the same emulated window as its embedder.
Previously, we were setting this on DocAccessibleParent, but we weren't sending it to content to make it available on DocAccessibleChild.
This meant that accessibles in out-of-process iframe documents were reporting the wrong window handle.
Differential Revision: https://phabricator.services.mozilla.com/D32788
--HG--
extra : moz-landing-system : lando
isSlowPlatform() is always false because we no longer support Android 2.3 or B2G.
Also remove unused functions isWindows32() and isAndroid(). They were added in bug 1485875, but the callers were later removed in Windows bug 1475564 and Android bug 1368843.
Depends on D33423
Differential Revision: https://phabricator.services.mozilla.com/D33424
--HG--
extra : moz-landing-system : lando
AV1-in-MP4 support was disabled on Win32 in bug 1417050 and re-enabled in bug 1475564. This Win32 check should have been removed at that time to re-enable this AV1-in-MP4 test on Win32.
Differential Revision: https://phabricator.services.mozilla.com/D33423
--HG--
extra : moz-landing-system : lando
SVGImageElement isn't really a SVGGeometryElement, we did that just for
better code sharing. BuildPath() won't be called for <image>.
Differential Revision: https://phabricator.services.mozilla.com/D33400
--HG--
extra : moz-landing-system : lando
It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible.
Among other things, this is the way accessibility events are targeted on Windows.
Previously, this code only searched remote documents at the top level of the tree.
In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process.
As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents.
This was already being sent from the content process, but previously, we didn't store this in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D32417
--HG--
extra : moz-landing-system : lando
Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received.
As part of this, we no longer try to send the parent COM proxy during construction of an OuterDocAccessible in the parent process.
This was previously a no-op anyway, as DocAccessibleParent::SendParentCOMProxy called DocAccessible::GetAccessible for the frame element, which would have returned null because the accessible isn't bound to the document until *after* it is constructed.
Changing this to directly pass the OuterDocAccessible was causing assertions in content processes, since it sometimes meant the parent COM proxy was sent twice, which is precisely what the assertion is protecting against.
Instead, the parent proxy is sent in Browserparent::RecvPDocAccessibleConstructor as it always was.
Differential Revision: https://phabricator.services.mozilla.com/D32284
--HG--
extra : moz-landing-system : lando
DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents.
Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document.
DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this.
BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D32282
--HG--
extra : moz-landing-system : lando
webidlsrcs.mk is treated specially by the build system, and this entire
process should be supported better by moz.build, but in the meantime this
fixes the clobber bug caused by not re-building these targets when defines
are updated.
Differential Revision: https://phabricator.services.mozilla.com/D33415
--HG--
extra : moz-landing-system : lando
This is done by sending a message over PBrowser and PBrowserBridge when the
event would fire to fire it in the correct process.
Differential Revision: https://phabricator.services.mozilla.com/D33083
--HG--
extra : moz-landing-system : lando
This is the more logical behaviour than the previous, where an unknown process
would be given the full "dom.ipc.processCount" process limit, which could lead
to unintentionally allocating a large # of processes.
Differential Revision: https://phabricator.services.mozilla.com/D32763
--HG--
extra : moz-landing-system : lando
This allows the # of processes to be specified for remote types like
"webIsolated", used by fission windows.
Differential Revision: https://phabricator.services.mozilla.com/D32762
--HG--
extra : moz-landing-system : lando
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
--HG--
extra : moz-landing-system : lando
This pref toggled gives me the desired behavior on Linux, and it should be
trivial to revert to the previous behavior if needed.
Depends on D33393
Differential Revision: https://phabricator.services.mozilla.com/D33394
--HG--
extra : moz-landing-system : lando
It's only moved around, but not actually used anywhere.
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D33393
--HG--
extra : moz-landing-system : lando
Remove a few no-longer-necessary `AllowCompilerWarnings()` before anything that depends upon them sneaks in.
Differential Revision: https://phabricator.services.mozilla.com/D33631
--HG--
extra : moz-landing-system : lando
Currently, BrowserChild rendering is enabled and disabled by `RecvRenderLayers`, and this
method is called only by the tab switching code.
This commit does several things.
1. It factors out the code to enable/disable rendering to MakeVisible/MakeHidden so it can
be used outside of `RecvRenderLayers`
2. We track the current value of RenderLayers and use it in conjunction with EffectsInfo to
determine if we need to be rendering at any given moment
3. We only apply RenderLayers to the root OOP browser (not OOP-iframes)
These changes together make it so that BrowserChild will render IFF 'visible' || 'renderLayers',
and will only apply 'renderLayers' to the root browser.
Differential Revision: https://phabricator.services.mozilla.com/D31473
--HG--
extra : rebase_source : 12ad66f514cf1217899af42ca3891fe7b3f897dc
extra : intermediate-source : 3cb9ddccccf320b19f0deae88cd990982b703022
extra : source : e2197dd98aaeeb3d80b65c9892a82d41c4adc80d
The root PBrowser actor needs special case visibility behavior to satisfy the async tab
switcher. This commit adds a flag to track whether a BrowserChild is part of the root
actor.
Differential Revision: https://phabricator.services.mozilla.com/D33046
--HG--
extra : rebase_source : 5f7cb11f77d41f3265d211e99713a1dad6ae2579
extra : intermediate-source : 49e4d0e4fc7ccfa7b2c58bb9b64534c2d569a881
extra : source : adcc870662770a99962e721bd3c5ff4c2616c21d
This commit adds RemoteBrowser::UpdateEffects for updating a remote browser's
EffectsInfo over IPC.
A following commit will actually use the EffectsInfo for
enabling/disabling rendering for a remote browser, and another
commit will actually use these IPDL methods.
Differential Revision: https://phabricator.services.mozilla.com/D31472
--HG--
extra : rebase_source : 304d843d2c4a35f468aa847ee66005a932bb7eb2
extra : intermediate-source : d31b7d33efc711fb8115663f4cfc5bc98fd58d73
extra : source : 5aea122dea2120efe107c639b17678e0464b1389
This commits adds EffectsInfo for tracking graphical effects
that are applied to a remote browser's ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D31471
--HG--
extra : rebase_source : 5c4cda4019095dbd00aa3bca2edff0dbd16e5ca8
extra : intermediate-source : b4d5865e33079a36f535501293f8aaec8b6bcf64
extra : source : e8e3d2d76d860c76ee351c8b10ed488fdac2d9fc
This commit adds two small fixes to make the OOP-iframe code more robust.
The first fixes a crash during shutdown for a tab that has OOP-iframes. It's
possible for the BrowserBridgeParent's to be shutdown before the root
BrowserParent. In this case, SetOwnerElement will run for the root BrowserParent,
but the child BrowserBridgeParent's will not have BrowserParent actors.
The second hooks up the BrowserBridgeParent constructor to actually use
the result code of BrowserBridgeParent::Init.
Differential Revision: https://phabricator.services.mozilla.com/D31477
--HG--
extra : rebase_source : bbe098c5ce75bd0fd26682a3b98f9958df5a2fcf
extra : intermediate-source : 83576499bf77d37e31b5328c0117650e57a03447
extra : source : 8f865f1f199c3e74844559a89b0ff642905513bd
This makes some callers a bit less awkward by not having, for example, to read
from the parent node or not depending on whether Element::BindToTree has been
called already or not.
Differential Revision: https://phabricator.services.mozilla.com/D33368
--HG--
extra : moz-landing-system : lando
We want to ensure the RDM browser's outer window sizes are not affected as the page is zoomed in or out. In the context of RDM, the size of the browser window will be the same as the viewport so I believe it's safe to assume that the window's outer size will be equal to its inner size when the zoom level is set to 100%.
I found we can get this value by using the presentation context's `GetDeviceZullZoom` method and applying it to the inner sizes of the RDM viewport.
Differential Revision: https://phabricator.services.mozilla.com/D32778
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
The removal of the second CSP check is fixing a regression introduced in bug
965637. See https://github.com/whatwg/html/issues/4651#issuecomment-495050351
for details. We may want to re-introduce that check depending on the outcome
of that issue, but if so we should do that only if the target document's
principal subsumes our triggering principal.
This commit will not allow bookmarklets to access subresources that
CSP blocks, but will at least allow them to run.
Differential Revision: https://phabricator.services.mozilla.com/D33047
--HG--
extra : moz-landing-system : lando
It appears that in some cases we can have the wrong value for the
WindowGlobalParent::DocumentURI. This patch adds another case in SetNewDocument
which should ideally catch the case where the Document is replaced while
preserving the inner window.
Differential Revision: https://phabricator.services.mozilla.com/D33081
--HG--
extra : moz-landing-system : lando