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
The class contains original full referrer and referrer policy will be
applied to the referrer.
Differential Revision: https://phabricator.services.mozilla.com/D17923
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
- 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
With these changes, XBL just runs in the window scope of whatever document it's
attached to. Since (outside of tests and "remote XUL") we no longer attach XBL
to web documents, this is fine. And "remote XUL" already ran without the XBL
scope.
Native anonymous content, which used to be placed in the XBL scope to hide it
from the page, is now placed in the unprivileged junk scope, so it stays hidden
from the page.
dom/xbl/test/test_bug944407.xul is being removed because we are changing the
behavior it's trying to test for. Since we now always put the XBL in the same
scope as the page, script is enabled for the XBL if and only if it's enabled for
the page.
dom/base/test/test_bug419527.xhtml, dom/events/test/test_bug391568.xhtml,
dom/xbl/test/test_bug1086996.xhtml are being switched to a chrome test because
otherwise the XBL can't see the getAnonymousNodes method.
All the XBL bits are being removed from test_interfaces because we no longer
have a separate XBL scope to test the behavior of.
js/xpconnect/tests/mochitest/test_nac.xhtml is being removed because XBL no
longer has access to NAC unless the page it's attached to does too, so the test
doesn't really make sense.
layout/xul/test/test_bug1197913.xul is being switched to a chrome test because
its XUL elements use bindings that rely on APIs that are not exposed to normal
web content.
layout/reftests/bugs/495385-2f.xhtml is being removed because I can't think of
a sane way to test that in the new world, short of running the reftest as
chrome. And it doesn't seem worthwhile to look for a way to do that.
dom/xbl/test/test_bug1098628_throw_from_construct.xhtml now needs to
expectUncaughtException(), because the exception is now being thrown in Window
scope.
dom/xbl/test/test_bug1359859.xhtml needs to expectUncaughtException() as needed
and not use XPCNativeWrapper (which it doesn't need to anyway now).
dom/xbl/test/test_bug389322.xhtml, dom/xbl/test/test_bug400705.xhtml,
dom/xbl/test/test_bug401907.xhtml, dom/xbl/test/test_bug403162.xhtml,
dom/xbl/test/test_bug526178.xhtml, dom/xbl/test/test_bug639338.xhtml don't need
to use XPCNativeWrapper anymore.
dom/xbl/test/test_bug821850.html is being removed because it exists only to test XBL scopes.
dom/xbl/test/file_bug950909.xml is being changed to work without a separate XBL
scope (though whether the test still makes sense at that point is a bit questionable).
Differential Revision: https://phabricator.services.mozilla.com/D19260
--HG--
extra : moz-landing-system : lando
Also for the intersection observer root margin, since it was easier to fix it
up and clean it up than not doing it.
This is the first big step to get rid of nscoord. It duplicates a bit of logic
in nsLayoutUtils since for now max/min-width/height are still represented with
nsStyleCoord, but I think I prefer to land this incrementally.
I didn't add helpers for the physical accessors of the style rect sides that
nsStyleSides has (top/bottom/left/right) since I think we generally should
encourage the logical versions, but let me know if you want me to do that.
Differential Revision: https://phabricator.services.mozilla.com/D17739
"input" event listener may want to check HTMLInputElement.validationMessage.
However, due to moving "input" event dispatcher from
HTMLInputElement::SetUserInput() to editor, HTMLInputElement::SetValueInternal()
updates it **after** dispatching "input" event.
This patch makes nsContentUtils::DispatchInputEvent() guarantees to update
validationMessage value before dispatching every event. On the other hand,
SetValueInternal() may be called without "input" event dispatchers. Therefore,
it needs to keep updating validationMessage value in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D19126
--HG--
extra : moz-landing-system : lando
In vm/Iteration.cpp this inlines some functions because there's a single
caller now. Follow-up patches will do additional cleanup/optimization.
Differential Revision: https://phabricator.services.mozilla.com/D18926
--HG--
extra : moz-landing-system : lando
It was added in bug 1461696 probably for tracking whether bug 1460295
is a wide-spread issue or so. This deprecation was already part of
deprecated mutation event, so it's never output to console. It was
added purely for getting telemetry.
Given that related issues are now fixed, we no longer needs this.
Differential Revision: https://phabricator.services.mozilla.com/D18935
--HG--
extra : moz-landing-system : lando
Copy fonts loaded during a mozPrintCallback into the cloned document,
so they are available during printing.
Differential Revision: https://phabricator.services.mozilla.com/D18613
--HG--
extra : moz-landing-system : lando
This commit removes the dependency on RenderFrame from nsDisplayRemote so that
it can work in child processes with remote subframes. Instead nsDisplayRemote
now works with an nsFrameLoader, which will return the LayerId from either
the RenderFrame (for top-level remote browsers), or from RemoteFrameChild
(for remote subframes).
Differential Revision: https://phabricator.services.mozilla.com/D17448
--HG--
extra : source : 1e1b5cd23412a85fad19ab8ec5aacf31b3a9c9b6
extra : intermediate-source : a62c029510315d109faa9edb31216014e7c70367
extra : histedit_source : 3df246e632fbb71f731c856779e0d2201b3673a3
This commit removes the dependency on RenderFrame from nsDisplayRemote so that
it can work in child processes with remote subframes. Instead nsDisplayRemote
now works with an nsFrameLoader, which will return the LayerId from either
the RenderFrame (for top-level remote browsers), or from RemoteFrameChild
(for remote subframes).
Differential Revision: https://phabricator.services.mozilla.com/D17448
--HG--
extra : rebase_source : c16611bf63b8fcb2e5de6a9cb8f54155f992fc32
extra : histedit_source : 6323f7756c5d3ebfbbe55148cb81503c512b9afb
A TabParent for a remote subframe will have the same owner content as the top-level
remote browser. This means that 'TabParent::GetFrameLoader()' will return the
frame loader of the top-level remote browser.
This is fine for getting the layer manager and compositor for connecting layer trees,
but the frame loader is also used to acquire a TabParent for its process ID. This
is incorrect in the remote subframe case, and will lead to the compositor rejecting
layer transactions for the remote subframe because it will only accept them from
the top-level remote browser's process.
This commit switches RenderFrame to just hold on to TabParent, and acquire the
nsFrameLoader as necessary.
Another change is to RenderFrame::SetOwnerContent. Previously this method would
take the new owner content and check an assertion. I don't see much value in the
assertion, so I've removed it. Additionally, now that we acquire the owner content,
and therefore the layer manager, from TabParent, we need to ensure that
RenderFrame::SetOwnerContent is ran after the TabParent has had it's owner content
updated. So the callsite has been moved into TabParent. This resolved a test failure
with frame loader swapping.
Differential Revision: https://phabricator.services.mozilla.com/D17447
--HG--
extra : source : 4c85fb68f2ed297828bf4646301c2d80d1c8e0a1
extra : intermediate-source : 62ad54fb95eb76f88865f43da1a5d556421e7884
extra : histedit_source : 6b7085118bca83433b26fcec3983a385bd536672
A TabParent for a remote subframe will have the same owner content as the top-level
remote browser. This means that 'TabParent::GetFrameLoader()' will return the
frame loader of the top-level remote browser.
This is fine for getting the layer manager and compositor for connecting layer trees,
but the frame loader is also used to acquire a TabParent for its process ID. This
is incorrect in the remote subframe case, and will lead to the compositor rejecting
layer transactions for the remote subframe because it will only accept them from
the top-level remote browser's process.
This commit switches RenderFrame to just hold on to TabParent, and acquire the
nsFrameLoader as necessary.
Another change is to RenderFrame::SetOwnerContent. Previously this method would
take the new owner content and check an assertion. I don't see much value in the
assertion, so I've removed it. Additionally, now that we acquire the owner content,
and therefore the layer manager, from TabParent, we need to ensure that
RenderFrame::SetOwnerContent is ran after the TabParent has had it's owner content
updated. So the callsite has been moved into TabParent. This resolved a test failure
with frame loader swapping.
Differential Revision: https://phabricator.services.mozilla.com/D17447
--HG--
extra : rebase_source : 7a4c6aede22c4c457b03803f794d6845f4fd6482
extra : histedit_source : 19692ca27b05c4b8a7eb521f432bc21a756e9085
This commit hooks up the pieces of the PRemoteFrame protocol that
will proxy initialization, sizing, and display messages. The messages
chosen are just enough to start the frame and get an initial rendering.
Differential Revision: https://phabricator.services.mozilla.com/D17445
--HG--
extra : source : b68b732411e2e1e6851799262246bff70e6649da
extra : intermediate-source : c19bc81c4f43a5adba92184b2572c09c6c5a0680
This commit hooks up nsFrameLoader in the child process to use the
PRemoteFrame protocol to support remote iframes. This is only activated
when a special pref is set, and the iframe has a marker attribute on it.
For example:
<iframe fission/>
In the future, we should unify nsFrameLoader to operate on a common
interface between the parent process top-level browser, and child
process subframe case. This commit just adds a new member that can
be used instead of mRemoteBrowser, when appropriate. IsRemoteFrame()
will return true for both cases.
Differential Revision: https://phabricator.services.mozilla.com/D17444
--HG--
extra : source : e33b9de7283e5fb6441e118b25af8d4ac3411bf2
extra : intermediate-source : 697a9159e0d260118ee6ebd34948d187a8c5359f
This commit hooks up the pieces of the PRemoteFrame protocol that
will proxy initialization, sizing, and display messages. The messages
chosen are just enough to start the frame and get an initial rendering.
Differential Revision: https://phabricator.services.mozilla.com/D17445
--HG--
extra : rebase_source : a361afeaa08e2bf450608ba6a3fd4040f155875a
extra : histedit_source : a2b33c6dbc756a323d825b29255da4a6343208bc
This commit hooks up nsFrameLoader in the child process to use the
PRemoteFrame protocol to support remote iframes. This is only activated
when a special pref is set, and the iframe has a marker attribute on it.
For example:
<iframe fission/>
In the future, we should unify nsFrameLoader to operate on a common
interface between the parent process top-level browser, and child
process subframe case. This commit just adds a new member that can
be used instead of mRemoteBrowser, when appropriate. IsRemoteFrame()
will return true for both cases.
Differential Revision: https://phabricator.services.mozilla.com/D17444
--HG--
extra : rebase_source : 7bab851665c0ed99be6ee1b47f6baad369410987
extra : histedit_source : 76ee7b1dd959a12080da4e683ff174ab3a04d84e