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
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
Because the root resolution is conceptually at the parent/child process
boundary, when sending mouse events from child to the parent, we need to
apply that resolution to the mouse coordinates.
Differential Revision: https://phabricator.services.mozilla.com/D8993
--HG--
extra : moz-landing-system : lando
PuppetWidget::StartPluginIME() calls TabChild::SendStartPluginIME()
with given WidgetKeyboardEvent instance. Then, the keyboard event
will be marked as "posted to remote process" by
ParamTraits<mozilla::WidgetEvent>::Write(). However, the method
sends back the keyboard event to the main process synchronously.
So, we don't want the event is treated as "posted" since the
flag is used to check whether current process handles posted event
*before* the remote process or not.
So, PuppetWidget::StartPluginIME() should restore the cross process
dispatching state with calling
WidgetEvent::ResetCrossProcessDispatchingState(). Unfortunately,
this also clears propagation state of the event too if the event
has already been posted to a remote process and is waiting reply
from the remote process. This shouldn't occur in content
process, however, we should check it with MOZ_ASSERT() for
detecting regressions.
Differential Revision: https://phabricator.services.mozilla.com/D7579
--HG--
extra : moz-landing-system : lando
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
Some InputContext members are not forwarded through
PBrowser::SetInputContext.
MozReview-Commit-ID: C1bGYq4w8zT
--HG--
extra : rebase_source : 1481f08c7593fe9dceb3b96bbfe480a1c58ecf9d
"alloc-failure" is completely unused apart from the description text in nsI-
Memory.idl (and has been since before Firefox 17), while "lowering-priority" is
still being checked for in the PuppetWidget, but otherwise unused as well since
the feature using it was decommissioned in bug 1234176.
Since we're touching the PuppetWidget code anyway, we take the opportunity to
add a check for "low-memory-ongoing" instead, since similar as to how things
used to be with "lowering-priority", we want to drop the LayerManager's cached
resources only when receiving a real full memory-pressure event, but not for
subsequent ongoing notifications.
MozReview-Commit-ID: HL03SOU8axe
--HG--
extra : rebase_source : c988769df36d8d77f4770c71d5c5e0d75c3b99af
When ContentCacheInParent::RequestIMEToCommitComposition() returns true,
the remote process will synthesize eCompositionCommit event. This causes
destroying TextComposition event in the remote process (by
IMEStateManager::DispatchCompositionEvent()). Then,
IMEStateManager::DispatchCompositionEvent() will recreate new TextComposition
instance when it receives new composition event. Then, it may request
to commit composition to the main process via PuppetWidget accidentally.
So, after PuppetWidget::RequestIMEToCommitComposition() synthesizes
eCompositionCommit, PuppetWidget should discard following composition events
until it receives eCompositionStart since they are unnecessary for the content
and they are for the old composition, i.e., outdated events.
MozReview-Commit-ID: BNRcoYxABpd
--HG--
extra : rebase_source : caea469afeed8cc373aeca33199ac0d570052569
The property in question is the offset from the content process to the
chrome process, but it gets called various things for historical
reasons. Let's be consistent and just call it the chrome offset
everywhere.
Also, in some places this was needlessly getting turned into a
nsIntPoint via ToUnknownPoint(), only to be turned back into a
LayoutDeviceIntPoint at all the use sites. So this patch also updates
some function signatures to avoid the needless conversion.
No functional changes.
MozReview-Commit-ID: AuhEUfa64Uj
--HG--
extra : rebase_source : 20e1895fefd944f98307a8437f977252ee2c3185
According to the log in crash reports, eCompositionCommitRequestHandled is
sent to ContentCacheInParent twice or more for a composition. This causes
breaking mPendingCompositionCount and mPendingEventsNeedingAck management.
Currently, nsIWidget::NotifyIME() should be called only by
TextComposition::RequestToCommit(). Therefore, the method should manage if
it should request it actually. If the composition has already received
eCompositionCommit(AsIs) event, it shouldn't request it because parent process
may have already stated new composition and it shouldn't be broken by request
for old composition.
MozReview-Commit-ID: 2ekSa6EIeRP
--HG--
extra : rebase_source : d23aa29ce7871e83b99cec8c15aff0c580e08fb4
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
