In out-of-process iframes, the refresh driver for the iframe process doesn't
trigger the UpdateIntersectionObservation function in cases where ancestor
document's viewports change because there is no way to know it happens inside
the iframe process. So instead, we trigger the function in
BrowserChild::RecvChildToParentMatrix which is called in response to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D61937
--HG--
extra : moz-landing-system : lando
Now, this method returns simply the result of of `IsMozBrowserElement()`.
In the old days, We used to have IsMozBrowserElement and IsMozBrowserOrApp,
where the latter was true if we had a mozapp or mozbrowser.
But with b2g removed, the app thing went away.
`IsMozBrowser()` is less used than `IsMozBrowserElement()`.
I think the former should be replaced by the later one.
Differential Revision: https://phabricator.services.mozilla.com/D61699
--HG--
extra : moz-landing-system : lando
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
The OnContentBlockingEvent is no longer needed once we make the
OnContentBlockingEvent parent only.
Differential Revision: https://phabricator.services.mozilla.com/D55788
--HG--
extra : moz-landing-system : lando
This patch adds an IPC message which allows content process to notify
the OnContentBlockingEvent in the parent process. This is needed because
there are some situations that the content blocking happens in content
processes, so we need to tell the parent process to notify it. Such as,
AntiTrackingCommon::AntiTrackingCommon::AddFirstPartyStorageAccessGrantedFor().
Differential Revision: https://phabricator.services.mozilla.com/D55648
--HG--
extra : moz-landing-system : lando
This makes clear where the information comes from, and also that there are some
bits of information that we should pass down from the child that we don't, like
allowfullscreen and the frame name.
Differential Revision: https://phabricator.services.mozilla.com/D58535
--HG--
extra : moz-landing-system : lando
The OnContentBlockingEvent is no longer needed once we make the
OnContentBlockingEvent parent only.
Differential Revision: https://phabricator.services.mozilla.com/D55788
--HG--
extra : moz-landing-system : lando
This patch adds an IPC message which allows content process to notify
the OnContentBlockingEvent in the parent process. This is needed because
there are some situations that the content blocking happens in content
processes, so we need to tell the parent process to notify it. Such as,
AntiTrackingCommon::AntiTrackingCommon::AddFirstPartyStorageAccessGrantedFor().
Differential Revision: https://phabricator.services.mozilla.com/D55648
--HG--
extra : moz-landing-system : lando
If `nsGlobalWindowOuter::ResizeTo()` etc is called before receiving
`BrowserChild::RecvUIResolutionChanged()`, the `aX`, `aY`, `aCx` and `aCy`
values are computed with old scale.
This patch makes `BrowserChild::SendSetDimensions()` set scale in the
remote process and `BrowserParent::RecvSetDimensions()` recompute each
value with current scale.
Differential Revision: https://phabricator.services.mozilla.com/D54150
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
* Removed the STATUS_LINK constant.
* Removed the statusType parameter from nsIWebBrowserChrome::setStatus.
* Removed the setStatusWithContext method. No one uses the information from
statusContext.
* Removed the nsIWebBrowserChrome2 interface as setStatusWithContext was the
only method.
Differential Revision: https://phabricator.services.mozilla.com/D55195
--HG--
extra : moz-landing-system : lando
The change to moz.build unveiled a couple unified build issues that I also had
to fix.
Depends on D55365
Differential Revision: https://phabricator.services.mozilla.com/D55366
--HG--
extra : moz-landing-system : lando
The dynamic toolbar transition doesn't affect on background tabs since to
switch tabs the dynamic toolbar should be restored to its original state (i.e.,
completely visible state).
Differential Revision: https://phabricator.services.mozilla.com/D52336
--HG--
extra : moz-landing-system : lando
This involves two new IPC messages (both async) to propagate the change in
compositor options (of which APZ enablement is one) from the GPU process to
the parent process (via PCompositorBridge) and on to the content process
(via PBrowser).
The support is only partial, in that going from non-APZ to APZ is only
supported if APZ was enabled at the time the window was created.
Depends on D51467
Differential Revision: https://phabricator.services.mozilla.com/D51468
--HG--
extra : moz-landing-system : lando
And deliver the value to the top content pres context, but it's not used in
this commit. The value will be used in the next commit.
One caveat is that areas covered by the dynamic toolbar will be outside
of the content area, which means implementers of GeckoView needs to call
setVerticalClipping with _negative_ values.
Depends on D50416
Differential Revision: https://phabricator.services.mozilla.com/D50417
--HG--
extra : moz-landing-system : lando
Prior to this patch, users entering javascript: URLs in the location bar
(e.g. via a bookmark) would trigger the cancel content JS path for the page
they were on, potentially breaking the site. Since javascript: URLs
(generally) don't navigate to a new page, we should avoid canceling the
current page's JS.
Differential Revision: https://phabricator.services.mozilla.com/D51951
--HG--
extra : moz-landing-system : lando
This event is useful for tests that resize the RDM pane and need to
know when all resolution adjusting effects are complete.
Differential Revision: https://phabricator.services.mozilla.com/D47364
--HG--
extra : moz-landing-system : lando
This event is useful for tests that resize the RDM pane and need to
know when all resolution adjusting effects are complete.
Differential Revision: https://phabricator.services.mozilla.com/D47364
--HG--
extra : moz-landing-system : lando
This event is useful for tests that resize the RDM pane and need to
know when all resolution adjusting effects are complete.
Differential Revision: https://phabricator.services.mozilla.com/D47364
--HG--
extra : moz-landing-system : lando
This flag is only meant for window.open() stuff, so not relevant to iframes at
all.
This preserves the current fission behavior (which is quite broken) of always
showing scrollbars.
The way to control scrollbars for iframes (the scrolling attribute) is not
handled at all for Fission, I filed a bug and left a few FIXMEs.
Differential Revision: https://phabricator.services.mozilla.com/D49292
--HG--
extra : moz-landing-system : lando
Currently when checking if a window supports protected media it's up to the
caller interacting with a BrowserChild to check if a response is already
cached, to perform the check if needed, and to then set the cached response if a
call was made. This patch moves that logic internal to Browser child so that
callers need to only worry about interacting with a single function.
Differential Revision: https://phabricator.services.mozilla.com/D48585
--HG--
extra : moz-landing-system : lando
aForceRepaint wasn't doing what it claimed to do at all, as we've recently
learned. In current mozilla-central:
* All those arguments ended up in a RecvRenderLayers with aForceRepaint = true
(so far so good, that's expected).
* But it was ignored (so that aForceRepaint is always true to calls to
MakeVisible) from UpdateVisibility:
https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/ipc/BrowserChild.cpp#2523
* Plus that argument only does anything useful on current central if we get to
the end of MakeVisible(true). And MakeVisible() early returns if already
visible.
So all in all this seems somewhat useless, and nobody has complained about such
a thing in a long time.
It seemed to do what it promised when it was introduced in
https://hg.mozilla.org/mozilla-central/rev/27f6f789b194, but it seems the
refactoring in https://hg.mozilla.org/mozilla-central/rev/4df5fa6fa785 broke it.
I think the new setup is somewhat easier to reason about, and nobody seems to be
missing that.
I'll try to remove the forceRepaint() call itself on a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D47127
--HG--
extra : moz-landing-system : lando
That is, for fission iframes. For top level stuff we rely on the tab switcher
going through SetDocShellIsActive and such.
See the expanded comment as for why. Ideally we could simplify this further by
not making RecvRenderLayers update the visibility (which spins the refresh
driver and such).
It's a bit suspect because it's very easy to get to an inconsistent state if the
browser chrome does something wrong.
I'll try to do that, but for now this should improve the fission situation
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D46706
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
Note that the areas are clipped out by all ancestor scroll ports and
their coordinate systems are the screen coordinate. So that we can tell
arbitrary elements in out-of-process iframes are scrolled out or not with
this area and the transform matrix of the iframe on screen coodinate.
Differential Revision: https://phabricator.services.mozilla.com/D44420
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/from a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/form a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/form a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
This patch also includes some spot fixes for the storage principal
support on the XUL browser element.
Differential Revision: https://phabricator.services.mozilla.com/D42203
--HG--
extra : moz-landing-system : lando
This also renames the existing infallible nsDocShell:GetBrowsingContext()
getter to BrowsingContextRef(), and changes the return type, since several
callers rely on it returning a raw pointer rather than an already_AddRefed.
Differential Revision: https://phabricator.services.mozilla.com/D40312
--HG--
extra : moz-landing-system : lando
Currently, TabGroups know to break their reference cycles only when the last
window leaves them. For TabGroups which have never had a window join (which
happens under Fission), this means they also never see a window leave, and
therefore never break their reference cycles, and leak.
This patch adds a check to break reference cycles if no windows have joined by
the time a BrowserChild they belong to is destroyed.
MANUAL PUSH: Lando fails to rebase.
Differential Revision: https://phabricator.services.mozilla.com/D40669
--HG--
extra : source : 03acb28ab60fb77fa06064385a62cc46cf4ad1bd
extra : amend_source : 0a71625d99951bebe45ee6f62570de491a714e97
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
So that paint doesn't reenter on layout, or mess with incomplete frame trees, or
what not.
I just early-returned rather than only skipping the PaintWhileInterruptingJS
call because I don't think we should be running untrusted scripts in the first
place when IsSafeToRunScript() is false.
Differential Revision: https://phabricator.services.mozilla.com/D39913
--HG--
extra : moz-landing-system : lando
This is an example refcounted actor which was easy enough to port over as an
initial test. More can be ported in the future, potentially alongside removing
`mIPCOpen`.
Differential Revision: https://phabricator.services.mozilla.com/D39503
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
App units of a remote browser element in the parent process are
different from app units inside the remote content in the child
process. We should apply the appropriate conversions by exposing
the relevant data as LayoutDevicePixel.
Differential Revision: https://phabricator.services.mozilla.com/D35334
--HG--
extra : moz-landing-system : lando
Using a precise visible rect for a top-level browser can cause an
artifact when resizing the window.
I believe this is caused by the message to resize the browser, and
the following paint, to be processed before the message with the
new visible rect.
We can be smarter about this, but in the interest of getting a
quick fix, this commit reverts the behavior here only for top-level
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D34935
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
The root displayport has some assumptions built into it about being positioned at
the origin and sized to the composition bounds that seem like they only apply to
the cross process root content document. This commit changes us to avoid taking
this code path for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34527
--HG--
extra : rebase_source : 026bb84b7ad086f508228620d19d9f459f28bf1d
visibleRect should affect both WR/layers, and scaling will only affect
layers.
Differential Revision: https://phabricator.services.mozilla.com/D34525
--HG--
extra : rebase_source : 49273db3e10088c9493f693d5f8b58864dcb01aa
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
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
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
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
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
When changing processes and therefore destroying/rebuilding
frameloaders, add ability to keep the browsing context around and add
it to the new frameloader.
Differential Revision: https://phabricator.services.mozilla.com/D26267
When changing processes and therefore destroying/rebuilding
frameloaders, add ability to keep the browsing context around and add
it to the new frameloader.
Differential Revision: https://phabricator.services.mozilla.com/D26267
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--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
***
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
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