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
Our implementation of this method was removed in bug 1070710. I forgot to remove the declaration in that bug.
Differential Revision: https://phabricator.services.mozilla.com/D7947
--HG--
extra : moz-landing-system : lando
This was separate because at some point in the past we were calling
-[ChildView drawRect:inContext:] from a separate draw-in-titlebar pass. That separate
pass was removed in bug 676241.
Depends on D7929
Differential Revision: https://phabricator.services.mozilla.com/D7931
--HG--
extra : moz-landing-system : lando
I don't think anybody has made use of this code in years.
Depends on D7927
Differential Revision: https://phabricator.services.mozilla.com/D7928
--HG--
extra : moz-landing-system : lando
This override was intended to ignore unnecessary nsChildView::Invalidate calls
when using main thread OpenGL. With OMTC, Gecko no longer calls Invalidate in
those cases, it just composites on the compositor thread, and the widget's main
thread code doesn't really hear about it. So this workaround is no longer necessary.
Depends on D7925
Differential Revision: https://phabricator.services.mozilla.com/D7927
--HG--
extra : moz-landing-system : lando
The main thread layer manager is always NONE, BASIC or CLIENT. It is never OPENGL anymore.
Main-thread OpenGL rendering was removed in bug 924403.
Depends on D7924
Differential Revision: https://phabricator.services.mozilla.com/D7925
--HG--
extra : moz-landing-system : lando
This was an experiment before we had e10s. It's no longer needed.
Depends on D7922
Differential Revision: https://phabricator.services.mozilla.com/D7924
--HG--
extra : moz-landing-system : lando
Many years ago, Gecko would sometimes call nsChildView::Invalidate during drawRect:.
This is no longer the case: Widget invalidations now only happen outside of drawRect,
usually from a refresh tick or from viewWillDraw.
Differential Revision: https://phabricator.services.mozilla.com/D7922
--HG--
extra : moz-landing-system : lando
The assertion was reasonable check before fixing bug 1446401. However,
this is currently valid situation in UI Events spec.
Differential Revision: https://phabricator.services.mozilla.com/D7578
--HG--
extra : moz-landing-system : lando
On Mojave (or later versions) defaultCenter doesn't get the
accessibilityDisplayShouldReduceMotion changes, we need to use
sharedWorkspace.notificationCenter instead.
Note that the reason why we use defaultCenter originally is that using
sharedWorkspace.notificationCenter to post a notification (for mochitest)
crashed on MacOSX 10.10 (on a try).
Differential Revision: https://phabricator.services.mozilla.com/D6201
--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
This copies over the early-exit conditions from MaybeDrawTitlebar which
is the non-WR codepath where this gets drawn. In particular, the
!mIsCoveringTitlebar clause is true when the titlebar is enabled.
MozReview-Commit-ID: 6B7vKYuyrRP
--HG--
extra : rebase_source : b8f73d2c4f9e582bdb018e6aa121e92d54c60334
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 344c380ddaaf42a1fd820a26b762c61ee9e2d524
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 35362bc94068103367f46b23a14cb3831cd86990
If a key combination causes text input, we need to dispatch keypress
events without alt/ctrl/meta modifiers since TextEditor won't handle
keyepress events whose altKey, ctrlKey or metaKey is true as inputting
text.
Currently, TextEventDispatcher sets mCharCode of eKeyPress event from
mKeyValue. Then, when altKey, ctrlKey or metaKey is true, it'll call
WillDispatchKeyboardEvent() and then, TextInputHandler needs to reset
the charCode value from native event information.
However, the problem is, TextInputHandler::InsertText() is called
with control character when control key is pressed and InsertText()
clears the modifier information before sending eKeyPress event to
TextEvenDispatcher so that TextEventDispatcher won't call
WillDispatchKeyboardEvent() even though control key is actually
pressed. Therefore, TextInputHandler cannot adjust charCode value
and modifier flags in some cases such as control + option + 'a'.
This patch makes InsertText() stop clearing the modifiers and
makes WillDispatchKeyboardEvent() do it instead. This procedure
is expected by TextEventDispatcher.
MozReview-Commit-ID: Ig6qgRBeQDh
--HG--
extra : rebase_source : 446e8af0e921946f3409d26ede70446248317673
Previously, a feature was added to trigger pinch-zooming on desktops using the
mousewheel and a modifier key of the user's choosing (behind a pref).
To make testing easier on Macs, we wanted to trigger pinch-zooming
through Mac trackpad gestures. This patch enables pinch zooming through
trackpad gestures when the prefs apz.allow-zooming and
dom.meta-viewport.enabled are set to true. Currently, tests for this feature
were performed manually.
We will be using this feature only for internal testing. Later on when zooming
on desktops is more well-behaved, we will create automated tests and ship it.
MozReview-Commit-ID: HQ9OsPA1HPM
--HG--
extra : rebase_source : 47e4efb28f7ecc1867c00486dcff02b8922d0fc0
This commit implements the auto-dir scrolling functionality in APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot
will be implemented in a future.
MozReview-Commit-ID: 9xai99x71gh
--HG--
extra : rebase_source : 118d188f730e3fb91d147b076a053cb04e622e55
