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