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 patch adds a telemetry probe to collect Input Source ID or Bundle ID of
IME when an IME open mode is selected by user. Input Source ID includes
input mode of IME, but Bundle ID does not so. In most languages, we need
to collect the former, but only for Japanese IME, we need to collect the
latter because non-Japanese IME's input mode is "how to input characters".
So, the input mode is important. However, Japanese IME's input mode is
"to input which type of characters". So, Japanese IME user may use multiple
input modes but we need only the IME mode. If we'd collect number of
each input mode users of Japanese language, it'd be difficult to count
how many users actually used typical Japanese IME since somebody may use
only a mode, some others may use only different modes.
So, this patch collects Input Source ID when non-Japanese IME is open and
Bundle ID when Japanese IME is open.
MozReview-Commit-ID: CltLrWVGyRk
--HG--
extra : rebase_source : 752dd00c4e43bda9586ed3ba498636bf5069ead2
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
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
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
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
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
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 66f8ee003d2f70111f4cff16d6e2d906ef4bf10b
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
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : fb1ff20aeebb7ac494227e62ba2101039578808c
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
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 34fb2ca94151403a6d7ffd5a8b840f00a8bb4afb
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
Remote WebExtension panels can cause us to recreate the widget for a view that
already has a size. In the past, popup widgets were always created with an
initial size of 0x0, so setting the initial size of the ChildView to 0x0
resulted in correct behavior because the window would be resized to the correct
size shortly afterwards, and resize the ChildView along with it via its auto
resizing mask.
When we recreate a widget which already has a known size, setting the initial
size to 0x0 is wrong. We need to set the ChildView's size so that it fills the
contentView of the popup window completely.
MozReview-Commit-ID: 53d3AX3z5h2
--HG--
extra : rebase_source : 7720a6dd12ad7f8efc102cd1430a9e1ed2f5ee0f
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
We don't have any binding in the tree that extends="xul:menupopup", which is the
only thing that would change the result. Also, I constrained it to the XUL
namespace instead of just checking the node name.
But again, we don't have non-XUL menupopups.
MozReview-Commit-ID: 7M0beoJI86Y
--HG--
extra : rebase_source : f50a186d5e78ca808d6c8873ec982663f4bbbde5
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
This API is deprecated (callers are supposed to be using
nsISound::playEventSound instead) and there are no callers remaining in
mozilla-central, or references to the strings for the API. Let's remove
dead code.
This implements the only useful piece of functionality that the
TitlebarAndBackgroundColor class was providing.
MozReview-Commit-ID: FXC6ICgDaoZ
--HG--
extra : rebase_source : fcd5b02ef057199df34459a4361ef7b4184d3a57
We no longer need the ability to specify a background color which gets drawn in
the titlebar. This was the only reason why we were using a textured window.
MozReview-Commit-ID: E8zizuvjjnA
--HG--
extra : rebase_source : ecd4d23e9bb068efbcd192b90e039809bdb451b0
Another patch in this patch series is going to remove our custom window
background color entirely, so we no longer need this override.
MozReview-Commit-ID: 5Hk8jiudzir
--HG--
extra : rebase_source : 24f067726b6c9ce9991dd11df19b726c327eaf05
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
This separates the methods that are used to deliver input events
synchronously over IPDL to the compositor; this interface will be
remoted over a new APZInputBridge IPDL protocol in future patches.
MozReview-Commit-ID: 1f3V9SUKlfW
--HG--
rename : gfx/layers/apz/public/IAPZCTreeManager.cpp => gfx/layers/apz/src/APZInputBridge.cpp
extra : rebase_source : 523abce7949baf9e3b7803a61632eb4434a6967f
First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event
before sending IME. This is different behavior from Gecko on the other
platforms and it means TextInputHandler does not know if the eKeyDown event
will be handled by IME. Therefore, we need to make TextInputHandler dispatch
an eKeyDown event dispatch when it needs to dispatch another event. Therefore,
this patch makes TextInputHandler not dispatch an eKeyDown even from
its HandleKeyDown() unless it's already has composition (because if it's
already had composition, any eKeyDown event except modifier keys should be
marked as "processed by IME" for compatibility with the other browsers).
For dispatching eKeyDown event only once for a native keydown event,
this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent()
to check whether eKeyDown event has already been dispatched for the event
and if it's not so, dispatches eKeyDown event.
Note that on macOS, dead keys are implemented as IME. However, we need to
treat dead keys as is. Therefore, if current keydown event is a dead keydown
event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching
eKeyDown event and its following eKeyDown event as "processed by IME".
MozReview-Commit-ID: 7epk8wdAznd
--HG--
extra : rebase_source : 0ed30ff3e108170fd96eabe626e0530473f2f3b1
In the past there were cases where treating double click behavior differently from draggability
was necessary, but there don't seem to exist such cases any more. For example, we don't have any
windows with bottom bars / draggable status bars any more.
This change simplifies the code and frees the frontend from having to use special -moz-appearance
values to indicate titlebary parts of the window.
MozReview-Commit-ID: IRe3FPU2EaT
--HG--
extra : rebase_source : e52b79d4cbc15b3c3a70b8411c5917309a7f78d8
It looks like the work in bug 1291457 was all that was necessary to get working
window shadows for accelerated popups. It seems that macOS is able to compute
the correct shadow style consistently for whatever is drawn in the
NSOpenGLContext during the first paint of the window (inside the drawRect call
during the orderFront call that opens the window).
We only ran into problems when we animated the contents of the window in a way
that affects the shadow style; we're no longer doing that after bug 1291457.
MozReview-Commit-ID: 62mfWuAsrg2
--HG--
extra : rebase_source : bf8121451474629f0194ccbb422147d5f05ff5b3
extra : source : 57b4a3dff2a5799c5c994a5b577b76c98ebc8226
Looking at the docs for [NSWindow title] I don't think it's supposed to return
nil under any circumstances...
But it does in our automation, for some reason, with the patches for bug 1439875
which make our fullscreen code run a bit earlier.
MozReview-Commit-ID: AX4qzjzsqST
--HG--
extra : rebase_source : a01f2ba6b42b4067e7a4886c4814e85f317a4a6f
Emilio Cobos Álvarez
Stephen A Pohl
Dale Harvey
Noemi Erli
Margareta Eliza Balazs
Xidorn Quan
Cosmin Sabou
Masayuki Nakano
Jeff Gilbert
Chris Peterson
Doug Thayer
Andi-Bogdan Postelnicu
Andreea Pavel
Mats Palmgren
Csoregi Natalia
Boris Zbarsky
Markus Stange
Dorel Luca
Bogdan Tara
Tanushree Podder
Narcis Beleuzu
Adrian Wielgosik
David Major
YUKI "Piro" Hiroshi
Milan Sreckovic
Dão Gottwald
Jonathan Watt
Jonathan Kew
Sebastian Hengst
Zhang Junzhi
Tristan Bourvon
Ciure Andrei
Tooru Fujisawa
Nicholas Nethercote
Johann Hofmann
Jeff Muizelaar
Nathan Froyd
Miko Mynttinen
Kartikaya Gupta
arthur.iakab
Brian Grinstead