These functions all have a single call site, and the call site clearly always
has rect in DesktopPixel units. So it makes sense to encode this in the API,
and propagate the strongly typed units.
Differential Revision: https://phabricator.services.mozilla.com/D67696
--HG--
extra : moz-landing-system : lando
If we want correct popup placement we need to use the right anchor rect
for gdk_window_move_to_rect under Wayland. Patch exports the anchor rect from the
nsMenuPopupFrame to be used in nsWindow.
This patch also fixes popup overflowing the screen by using the size returned from
gdk_window_move_to_rect for the nsMenuPopupFrame.
Differential Revision: https://phabricator.services.mozilla.com/D67810
--HG--
extra : moz-landing-system : lando
`inputmode=none` has to close software keyboard. `inputmode` value is lower
case except to `mozAwesomebar` by bug 1618763, so we don't have to use
`equalsIgnoreCase` for `inputmode`.
Differential Revision: https://phabricator.services.mozilla.com/D67459
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Depends on D68146
Differential Revision: https://phabricator.services.mozilla.com/D68147
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D68146
--HG--
extra : moz-landing-system : lando
This patch computes the author-specified properties during the CSS cascade, and
removes the complex rule-tree-based implementation that tries to do the cascade
again.
This changes behavior in two ways, one of them which is not observable to
content, I believe:
* revert now re-enables the native styling. This was brought up in
https://github.com/w3c/csswg-drafts/issues/4777 and I think it is a bug-fix.
This is observable to content, and I'm adding a test for it.
* We don't look at inherited styles from our ancestors when `inherit` is
specified in a non-author stylesheet. This was introduced for bug 452969 but
we don't seem to inherit background anymore for file controls or such. It
seems back then file controls used to have a text-field.
I audited forms.css and ua.css and we don't explicitly inherit
padding / border / background-color into any nested form control.
We keep the distinction between border/background and padding, because the later
has some callers. I think we should try to align with Chromium in the long run
and remove the padding bit.
We need to give an appearance to the range-thumb and such so that we can assert
that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new
internal value for that.
Differential Revision: https://phabricator.services.mozilla.com/D67722
--HG--
extra : moz-landing-system : lando
On Windows, `AltGr` modifier state is represented with activating both
`Alt` and `Ctrl` modifiers. I.e., when `AltGr` is pressed, any shortcut
keys whose modifier require `Control` and/or `Alt` because `NativeKey`
needs to consume both flags and set modifier state to only `AltGraph`.
That means that we don't need to dispatch `eKeyPress` event when `AltGr` key
is pressed and the key does not produce a character since we've stopped
dispatching non-printable `keypress` events on web content.
See the automated test changes for the detail in chrome script handling for
its detail.
Differential Revision: https://phabricator.services.mozilla.com/D68311
--HG--
extra : moz-landing-system : lando
This patch computes the author-specified properties during the CSS cascade, and
removes the complex rule-tree-based implementation that tries to do the cascade
again.
This changes behavior in two ways, one of them which is not observable to
content, I believe:
* revert now re-enables the native styling. This was brought up in
https://github.com/w3c/csswg-drafts/issues/4777 and I think it is a bug-fix.
This is observable to content, and I'm adding a test for it.
* We don't look at inherited styles from our ancestors when `inherit` is
specified in a non-author stylesheet. This was introduced for bug 452969 but
we don't seem to inherit background anymore for file controls or such. It
seems back then file controls used to have a text-field.
I audited forms.css and ua.css and we don't explicitly inherit
padding / border / background-color into any nested form control.
We keep the distinction between border/background and padding, because the later
has some callers. I think we should try to align with Chromium in the long run
and remove the padding bit.
We need to give an appearance to the range-thumb and such so that we can assert
that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new
internal value for that.
Differential Revision: https://phabricator.services.mozilla.com/D67722
--HG--
extra : moz-landing-system : lando
- Integrate scale factor setup to moz_container_get_wl_surface() and don't call it explicitly.
- No need to set it explicitly at nsWindow::GetWaylandSurface().
- Update client offset when scale changes in CSD mode by UpdateClientOffsetFromCSDWindow().
- Update scale factor/opaque region on EGL immediately.
Differential Revision: https://phabricator.services.mozilla.com/D68352
--HG--
extra : moz-landing-system : lando
To paint outline: auto, we paint the focused border of a GTK_ENTRY_PAINT.
We're also adding the padding of the entry, and that's wrong and causes
undesirable padding that looks bogus.
Differential Revision: https://phabricator.services.mozilla.com/D68191
--HG--
extra : moz-landing-system : lando
`TSFTextStore::sHandlingKeyMsg` refers pointer of struct, but referred via
`TSFTextStore::PendingAction` so that we should make it has a copy of
`sHandlingKeyMsg` because of for async handling.
Differential Revision: https://phabricator.services.mozilla.com/D68049
--HG--
extra : moz-landing-system : lando
By painting focus colors. I suspect this was mostly an oversight? But it is the
most obvious issue I always find with this theme.
I followed active > focus > hover, which seems to match what GTK does (and makes
sense, generally).
Differential Revision: https://phabricator.services.mozilla.com/D68088
--HG--
extra : moz-landing-system : lando
Only button / menulist-button were missing from the hard-coded if condition. I
don't think we ever want to override author padding, and this can cause compat
issues as the one in this bug.
I'm making HasAuthorSpecifiedRules fast in bug 1624080, btw.
Differential Revision: https://phabricator.services.mozilla.com/D68085
--HG--
extra : moz-landing-system : lando
By painting focus colors. I suspect this was mostly an oversight? But it is the
most obvious issue I always find with this theme.
I followed active > focus > hover, which seems to match what GTK does (and makes
sense, generally).
Differential Revision: https://phabricator.services.mozilla.com/D68088
--HG--
extra : moz-landing-system : lando
Only button / menulist-button were missing from the hard-coded if condition. I
don't think we ever want to override author padding, and this can cause compat
issues as the one in this bug.
I'm making HasAuthorSpecifiedRules fast in bug 1624080, btw.
Differential Revision: https://phabricator.services.mozilla.com/D68085
--HG--
extra : moz-landing-system : lando
Let's use GtkInputPurpose and GtkInputHints by inputmode for software keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D67771
--HG--
extra : moz-landing-system : lando
Let's use GtkInputPurpose and GtkInputHints by inputmode for software keyboard.
Depends on D67770
Differential Revision: https://phabricator.services.mozilla.com/D67771
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando