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 should hopefully allow the parent process to tell whether a given document
is the initial about:blank document.
Differential Revision: https://phabricator.services.mozilla.com/D33542
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
This class is only inherited by BrowserChild and seems to be a remnant of
the B2G days.
Differential Revision: https://phabricator.services.mozilla.com/D33567
--HG--
extra : rebase_source : 504b3185b4cf59bcd4150935b9569641fbf8f844
extra : source : 82604ba5659a292616a10d19ad3f977b3094b33e
extra : histedit_source : 24b70700a41aeac53e2f34bf1f190867ffb75af6
This lets us get the TabId for the PBrowser created via PBrowserBridge in the embedding process.
Differential Revision: https://phabricator.services.mozilla.com/D33565
--HG--
extra : rebase_source : 32f4b465426e4d19e4a81df0fc67076b0132038b
extra : source : 5e938107e10ed489477d104c70e413e0c4e6091d
extra : histedit_source : 24bda5ef39697eb4ba9e691d4a3afcc5f144737b
RenderFrame is a very poor name for what this class does. RemoteLayerTreeOwner
isn't perfect (it's not the only thing that owns layer trees), but it's
hopefully clearer.
Differential Revision: https://phabricator.services.mozilla.com/D33564
--HG--
rename : layout/ipc/RenderFrame.cpp => layout/ipc/RemoteLayerTreeOwner.cpp
rename : layout/ipc/RenderFrame.h => layout/ipc/RemoteLayerTreeOwner.h
extra : rebase_source : 890e54b93f5979a2430c35028110aa7f2091c550
extra : source : f50dd4cde03beb99ed27397e06f81748ae87b727
extra : histedit_source : 2d7eed25156829b2502f1712880df962a781adcf
Code outside of BrowserParent should just get the LayersId from a getter
and not worry about RenderFrame.
Differential Revision: https://phabricator.services.mozilla.com/D33562
--HG--
extra : rebase_source : 63f9f9680a7cb16a18d9e56999e02a124aa63429
extra : source : e86839ca63260b09184755c98890fa8abf371530
extra : histedit_source : 34333f5f78ecf9b4f3e12c6175a6e81724a41fb2
gfxPlatform::GetSourceSurfaceForSurface and CreateDrawTargetForSurface
are both static methods that we sometimes use via the pattern
gfxPlatform::GetPlatform()->... This is problematic because this forces
gfxPlatform to be initialized in the process, and in the GPU process, we
don't support this. It should be safe to call these methods without
initializing gfxPlatform, so this patch removes the GetPlatform() call.
GetSourceSurfaceForSurface may end up initializing gfxPlatform anyways,
depending on whether or not a DrawTarget was given. This should not be a
concern for the crashes observed in bug 1435586.
Differential Revision: https://phabricator.services.mozilla.com/D33785
From this point on, the webkit-prefixed CSS features that were previously
protected by this pref will now be unconditionally enabled.
Differential Revision: https://phabricator.services.mozilla.com/D33807
--HG--
extra : moz-landing-system : lando
(The pref is about to be removed, but even before its removal, it defaults to
'true' so these tests don't need to bother setting/checking it.)
Differential Revision: https://phabricator.services.mozilla.com/D33805
--HG--
extra : moz-landing-system : lando
In particular:
- The tests test_disabled_properties.html and
test_animations_with_disabled_properties.html just want to be able to toggle
some pref to turn off some property. So, this patch changes them to use a more
recently-added pref-controlled property (-webkit-line-clamp). (We'll probably
have to update these tests again when we eventually remove the pref for that
property. Oh well.)
- The tests 1265611-1.html and test_transitions_with_disabled_properties.html
are more picky -- they require a pref-controlled property **whose initial value
is 'currentcolor'**. We don't have any such property anymore, once the
layout.css.prefixes.webkit pref is removed. For the crashtest, we might as
well keep the test, with a disclaimer that its tested codepath has changed.
And for the mochitest, we can't really "fix" the test, so let's just remove
it. (We can take some comfort in knowing that the still-present test
'test_animations_with_disabled_properties' is very similar and covers some of
the same codepaths.)
Differential Revision: https://phabricator.services.mozilla.com/D33804
--HG--
extra : moz-landing-system : lando
We already don't allow cross origin POST redirects on 307 redirects,
this adds extra guards to make sure we don't allow them on 308s
either.
Differential Revision: https://phabricator.services.mozilla.com/D28927
--HG--
extra : moz-landing-system : lando
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
