No longer called. This was done as an optimization for OOP iframes, but
it affects the scrollport so it's clearly not sound (the visible rect
shouldn't affect the layout scroll port).
If very tall OOP iframes are a problem somehow, it's something that we
need to deal with in another place. It was, in fact, removed for
top-level remote iframes because of bug 1554861 and other regressions.
Depends on D80731
Differential Revision: https://phabricator.services.mozilla.com/D80732
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--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
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
A mochitest for this change will be landed in bug 1614268 which needs
a work to make Element.focus() work in OOP iframes (bug 1556627).
Differential Revision: https://phabricator.services.mozilla.com/D62191
--HG--
extra : moz-landing-system : lando
With this change we have the same setup for prefers-reduced-motion so that
we can change the value with the same manner in automated tests.
Differential Revision: https://phabricator.services.mozilla.com/D59023
--HG--
extra : moz-landing-system : lando
With this change we have the same setup for prefers-reduced-motion so that
we can change the value with the same manner in automated tests.
Differential Revision: https://phabricator.services.mozilla.com/D59023
--HG--
extra : moz-landing-system : lando
The reason of the crash is, the window may have already been destroyed and
`PuppetWidget::mBrowserChild` was set to `nullptr` when synthesizing key event.
This patch makes `PuppetWidget::GetEditCommands()` check whether it's `nullptr`
and returns whether it's succeeded or not. Therefore, `TextInputProcessor`
can throw exception in such case.
Differential Revision: https://phabricator.services.mozilla.com/D52308
--HG--
extra : moz-landing-system : lando
Before this patch, we only considered the primary screen when deciding
whether or not WebRender should be enabled. This is problematic for
Intel users where we don't want to turn on WebRender for large screens;
several small screens are just as bad as one large screen. Now we sum
the pixel count for all the screens when making this decision.
Differential Revision: https://phabricator.services.mozilla.com/D46066
--HG--
extra : moz-landing-system : lando
Most of things will likely be no real change because they ask for the exact frame they want immediately before.
Differential Revision: https://phabricator.services.mozilla.com/D44359
--HG--
extra : moz-landing-system : lando
Converts browser.tabs.remote.desktopBehavior to a static pref. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42390
--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
This change was suspect to not work under full page zoom, but I thought it
would be okay as it would only affect OOP-iframes. That was not true.
Differential Revision: https://phabricator.services.mozilla.com/D35190
--HG--
extra : moz-landing-system : lando
Even if we don't have a root displayport, the composition size is still used for
displayport margins calculations. For extremely tall iframes, this will create
a displayport that is way to big. We should instead report a composition size that
is equivalent to the visible rect for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34528
--HG--
extra : rebase_source : 1f43cb16a0841eb3cd892401c83a46d56276cf2e
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
When user moves focus to an editable content in a content process, it posts
IME-focus notification to the main process. Then, when the main process
prepares IME/keyboard handling in editable content, it posts back IME
notification requests to the content process. Then, the content process's
`PuppetWidget` modifies its IME notification requests, but **not** modifying
cache of IME notification requests in its `TextEventDispatcher`. Therefore,
`IMEContentObserver` keep referring older IME notification requests which are
initialized without IME-focus. Note that `IMEContentObserver` caches the
*reference* of cached IME notification requests in `TextEventDispatcher`.
So, we need to refresh only the cache of IME notification requests in
`TextEventDispatcher`.
Differential Revision: https://phabricator.services.mozilla.com/D32821
--HG--
extra : moz-landing-system : lando
This patch makes `TabChild` use `mozilla::PresShell` directly.
Then, renames `TabChild::GetPresShell()` and `TabChild::GetDocument()` to
`TabChild::GetTopLevelPresShell()` and `TabChild::GetTopLevelDocument()` to
make what they do clearer (e.g., see the change in `PresShell.cpp`).
Differential Revision: https://phabricator.services.mozilla.com/D26455
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
So that we can query the test value in the child process properly.
Note that the APIs used for setting the prefers-reduced-motion value for testing
are only used on Android and MacOSX. As for MacOSX we have a different
machinery (see bug 1486971) to deliver the test value without spinning native
event loop in the child process so the change here is valid only for Android.
Differential Revision: https://phabricator.services.mozilla.com/D18311
--HG--
extra : moz-landing-system : lando
