Current implementation of Blink and WebKit is that enter key is dispatched
even if `enterkeyhint` is `next`. If no enterkeyhint, Gecko and Blink infer
this type from `<form>` and `<input>` element.
If this key is set as "next" by inference, Blink doesn't dispatch key event
then sets focus to next element, and Gecko dispatches `Tab` key to set focus
to next element.
So if action hint is "next" by inference, we would like to change to another
type "maybenext".
Differential Revision: https://phabricator.services.mozilla.com/D79645
Set enterkeyhint to `InputContext.mActionHint`. Although it is used by
`moz_action` attribute, enterkeyhint is standardized version of this.
New logic is the following.
1. Read `enterkeyhint` that is from editing host
2. Read `moz_action` on `<input>` element if no `enterkeyhint`
3. If both is nothing, we infer this value from the `<form>`.
Differential Revision: https://phabricator.services.mozilla.com/D79644
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This moves the clipping responsibility into the layer. It also brings back
assertions that make sure that no invalid content reaches the screen.
On the layer side I'm renaming validRect to displayRect, because at the time
NextSurface* is called, that rect is not yet valid.
This implementation also allows having valid content outside of the display
rect. So, for example, if you grow and shrink the display rect multiple times
but most of the outer parts are transparent, in theory this allows you to paint
the transparent pixels only once rather than every time the display rect
expands.
Differential Revision: https://phabricator.services.mozilla.com/D79842
This patch does the following things:
1. Use `FetchImageHelper` to fetch the MediaImage defined in
media-session
2. Upon the above image is fetched, set it to the SMTC's thumbnail
Differential Revision: https://phabricator.services.mozilla.com/D77893
- Group related functions together
- Sync the function order in .cpp and .h (except destructor)
- Rename `Update` to `RefreshDisplay`
Differential Revision: https://phabricator.services.mozilla.com/D77888
By assert mConrols instread of mInitialized in SetControlAttributes, we
no longer need to call SetControlAttributes after setting mInitialized
to true. Also, this patch change the timing to set mInitialized to true
so we can call SetControlAttributes before RegisterEvent. By doing so,
we no longer need to call UnregisterEvents when SetControlAttributes
fails.
Differential Revision: https://phabricator.services.mozilla.com/D77885
- Add error messages so it's easier to debug when the error occurs
- It's better to unregister the event listener if failed to open SMTP.
(In release, the key-event listener may be alive when the SMTP isn't
initialized successfully)
Differential Revision: https://phabricator.services.mozilla.com/D77884
`HStringRefernece` must be constructed with a non-null `wchar_t*`. The
raw pointer returned from `nsString::get()` is a non-null address so
it's ok to add an assertion in `SetMusicMetadata`.
Differential Revision: https://phabricator.services.mozilla.com/D77881
We've had nsNativeBasicTheme enabled since 75, and all reported issues
were fixed real soon (and I haven't heard of any of them recently).
Given the non-native theme is likely changing in the future, I'd rather
not maintain three themes for Android :)
Differential Revision: https://phabricator.services.mozilla.com/D80105
