I'm about to use them more in the front-end, and it'd be nice if these
did the right thing.
For that, make our stand-ins system return the Firefox titlebar colors.
Put the Windows "show accent color on title bars" code behind a pref
because we don't support it. I filed bug 1851155 to consider enabling it
by default.
After this changes there's only one place to tweak the (cross-platform)
titlebar colors (in nsXPLookAndFeel), with high-contrast mode and so on
behaving correctly by default.
The macOS special-case for the titlebar is to preserve the current
behavior from bug 1711261. If we want to change that to also apply to
dark mode or what not, we can do it in a follow-up.
I didn't bother putting the new colors in test_bug232227. That only
(tries to) test that we return fixed colors when the rfp/stand-ins prefs
are on. But we don't need to test the exact value of all the colors.
Differential Revision: https://phabricator.services.mozilla.com/D187278
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1571516#c24, we don't
currently store diagnostic data like the value of `::GetLastError()` in
stack dumps. However, we do store the current stack, and that's enough
to be usable.
Store some additional (critical?) diagnostic information in local
variables on the stack... and disable optimizations for that function,
to ensure that those variables actually exist in the stack-dump.
Arguably, no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186988
Pull the failing section of code out into its own function, for the sake
of clarity of later diffs.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186987
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1571516#c24, we don't
currently store diagnostic data like the value of `::GetLastError()` in
stack dumps. However, we do store the current stack, and that's enough
to be usable.
Store some additional (critical?) diagnostic information in local
variables on the stack... and disable optimizations for that function,
to ensure that those variables actually exist in the stack-dump.
Arguably, no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186988
Pull the failing section of code out into its own function, for the sake
of clarity of later diffs.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D186987
This only hides the cursor if it's on the page you're editing, but given
that the point of the feature is to move the cursor out of the way, that
seems acceptable (and honestly it feels more of a feature than a bug).
This should work across platforms (though non-windows platforms need
ui.hideCursorWhileTyping=1 in about:config to enable).
Differential Revision: https://phabricator.services.mozilla.com/D171155
A lone surrogate should not appear in `DOMString` at least when the attribute
values of events because of ill-formed UTF-16 string.
`TextEventDispatcher` does not handle surrogate pairs correctly. It should not
split surrogate pairs when it sets `KeyboardEvent.key` value for avoiding the
problem in some DOM API wrappers, e.g., Rust-running-as-wasm.
On the other hand, `.charCode` is an unsigned long attribute and web apps
may use `String.fromCharCode(event.charCode)` to convert the input to string,
and unfortunately, `fromCharCode` does not support Unicode character code
points over `0xFFFF`. Therefore, we may need to keep dispatching 2 `keypress`
events per surrogate pair for the backward compatibility.
Therefore, this patch creates 2 prefs. One is for using single-keypress
event model and double-keypress event model. The other is for the latter,
whether `.key` value never has ill-formed UTF-16 or it's allowed.
If using the single-keypress event model --this is compatible with Safari and
Chrome in non-Windows platforms--, one `keypress` event is dispatched for
typing a surrogate pair. Then, its `.charCode` is over `0xFFFF` which can
work with `String.fromCodePoint()` instead of `String.fromCharCode()` and
`.key` value is set to simply the surrogate pair (i.e., its length is 2).
If using the double-keypress event model and disallowing ill-formed UTF-16
--this is the new default behavior for both avoiding ill-formed UTF-16 string
creation and keeping backward compatibility with not-maintained web apps using
`String.fromCharCode`--, 2 `keypress` events are dispatched. `.charCode` for
first one is the code of the high-surrogate, but `.key` is the surrogate pair.
Then, `.charCode` for second one is the low-surrogate and `.key` is empty
string. In this mode, `TextEditor` and `HTMLEditor` ignores the second
`keypress`. Therefore, web apps can cancel it only with the first `keypress`,
but it indicates the `keypress` introduces a surrogate pair with `.key`
attribute.
Otherwise, if using the double-keypress event model and allowing ill-formed
UTF-16 --this is the traditional our behavior and compatible with Chrome in
Windows--, 2 `keypress` events are dispatched with same `.charCode` values as
the previous mode, but first `.key` is the high-surrogate and the other's is
the low surrogate. Therefore, web apps can cancel either one of them or
both of them.
Finally, this patch makes `TextEditor` and `HTMLEditor` handle text input
with `keypress` events properly. Except in the last mode, `beforeinput` and
`input` events are fired once and their `data` values are the surrogate pair.
On the other hand, in the last mode, 2 sets of `beforeinput` and `input` are
fired and their `.data` values has only the surrogate so that ill-formed
UTF-16 values.
Note that this patch also fixes an issue on Windows. Windows may send a high
surrogate and a low surrogate with 2 sets of `WM_KEYDOWN` and `WM_KEYUP` whose
virtual keycode is `VK_PACKET` (typically, this occurs with `SendInput` API).
For handling this correctly, this patch changes `NativeKey` class to make it
just store the high surrogate for the first `WM_KEYDOWN` and `WM_KEYUP` and use
it when it'll receive another `WM_KEYDOWN` for a low surrogate.
Differential Revision: https://phabricator.services.mozilla.com/D182142
In order to bring the GMP process in closer alignment with how other
special purpose processes work, we need to be able to use the same
component services generally expected. This patch makes the GMP process
allow the same services as seen in the GPU/VR/RDD/Utility processes.
Differential Revision: https://phabricator.services.mozilla.com/D185336
If we enter `SpinEventLoopUntil` while certain Windows events are
waiting for resolution, we may enter an unusable state.
Since removing all `SpinEventLoopUntil` instances -- or even the one
causing this problem -- isn't really an option at present, kick the can
down the road by kicking the can down the road [sic].
Differential Revision: https://phabricator.services.mozilla.com/D185969
In order to bring the GMP process in closer alignment with how other
special purpose processes work, we need to be able to use the same
component services generally expected. This patch makes the GMP process
allow the same services as seen in the GPU/VR/RDD/Utility processes.
Differential Revision: https://phabricator.services.mozilla.com/D185336
This doesn't change behavior yet because the front-end doesn't use them for the
cases where we're changing behavior, but this is in preparation to use them
unconditionally in the front-end and simplify a bit the code there.
Since we need generic colors, and the default theme light colors are not
particularly useful (they are windows-xp-like titlebar colors), I think this
makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D184707
In particular, spinner buttons, checkboxes, radio buttons, and the
menulist arrow.
These are all windows-style anyways, and look better than the native
counter-parts because they support webrender, zooming and scaling, etc.
The easiest way to see some of this in action is using ./mach run -P.
Differential Revision: https://phabricator.services.mozilla.com/D184648
Remove calls to `IsWin10OrLater()`.
The Windows 7 taskbar does not have this particular race condition, so
there is no need to perform it there. As Firefox no longer supports
Windows 7, there is no need for these checks in Nightly; they existed
solely to simplify uplift of that commit to ESR (which _does_ still
support Win7).
Differential Revision: https://phabricator.services.mozilla.com/D184774
Remove `widget.windows.alternate_fullscreen_heuristics` and all logic
dependent thereupon, since no one has reported any issues with it in the
year or so it's been present.
Differential Revision: https://phabricator.services.mozilla.com/D184763
To work around a race condition involving unminimizing windows, post a
message to our own message queue, to notify the taskbar that fullscreen
state recalculation is potentially necessary. (This notification must
occur _after_ we have finished processing the `WM_WINDOWPOSCHANGING`
message.)
Differential Revision: https://phabricator.services.mozilla.com/D184762
Everytime I look at this code I find more stuff to remove... :)
-moz-default-appearance: groupbox is not used anywhere.
menulist-text is, but it does nothing (it only would prevent drawing a
background, but we don't specify another background anyways).
Differential Revision: https://phabricator.services.mozilla.com/D184647
On the release channel, do not suppress overriding the scroll distance on
Windows when:
- The setting for the number of lines to scroll per mousewheel tick is not the
default
- The scroll speed is fast.
Differential Revision: https://phabricator.services.mozilla.com/D184621
Emilio Cobos Álvarez
Iulian Moraru
Nicholas Rishel
Ray Kraesig
Butkovits Atila
Masayuki Nakano
Andrew Osmond
Cristian Tuns
Masatoshi Kimura
Gregory Pappas
Peter Van der Beken
Jonathan Kew
Natalia Csoregi
Dan Robertson
Tooru Fujisawa
Chris Martin
Kagami Sascha Rosylight