Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--HG--
extra : moz-landing-system : lando
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--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 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
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
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
Now
* nsPresContext::mVisibleArea is excluding the toolbar max height so that
ICB is now static regardless of the dynamic toolbar transition
* nsPresContext::mSizeForViewportUnits is introduced to resolve viewport units
which is including the toolbar max height
That means that with the dynamic toolbar max height;
mVisibleArea < mSizeForViewportUnits
See https://github.com/bokand/URLBarSizing for more detail backgrounds of this
change.
Depends on D50417
Differential Revision: https://phabricator.services.mozilla.com/D50418
--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
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
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
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
Simon Giesecke
Makoto Kato
Csoregi Natalia
Daniel Varga
Alphan Chen
Ehsan Akhgari
Hiroyuki Ikezoe
Tetsuharu OHZEKI
Kris Maglione
Dimi Lee
Tim Huang
Emilio Cobos Álvarez
Ciure Andrei
Oana Pop Rus
Gabriele Svelto
Dorel Luca
Masatoshi Kimura
Botond Ballo
Bryce Seager van Dyk
thomasmo
Agi Sferro
Brad Werth
Sebastian Streich
Nika Layzell