This semicolon workaround is tidier than the `// clang-format off/on` comments and avoids turning off all clang-format checks. The comment also links to clang-format bug 1629756 so future code readers can learn why this extra semicolon exists. And if we find a way to fix this in clang-format, then we can search for this bug number to find and remove these extra semicolons and comments.
Differential Revision: https://phabricator.services.mozilla.com/D71504
nsBaseWidget::AllowWebRenderForThisWindow() limits WebRender usage to some type of windows. It was added by Bug 1377321, because initialization of WebRender was heavy weight in the past. It is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D71440
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
No one seems to reference `dom.event.touch.coalescing.enabled` after landing Bug 1291373.
So remove it.
Differential Revision: https://phabricator.services.mozilla.com/D70794
--HG--
extra : moz-landing-system : lando
Old NDK requires AKEYCODE defines for newer API version, but it is unnecessary
to define it when using NDK r20.
Differential Revision: https://phabricator.services.mozilla.com/D70786
--HG--
extra : moz-landing-system : lando
Currently, there is a cyclic reference between `ImageDecoderListener` and `ImageCallbackHelper` that causes a memory leak on Android. `ImageDecoderListener` is holding `imgIContainerCallback` which is a `ImageCallbackHelper` and `ImageCallbackHelper` is holding `imgIContainer`, which is actually a `ImageDecoderListener`.
Therefore, we should break the cyclic reference after receiving decoded image.
Differential Revision: https://phabricator.services.mozilla.com/D70468
--HG--
extra : moz-landing-system : lando
Change the GetScreenCapturePermissionState() heuristic to use the full window list instead of just on-screen windows to allow it it to work in full screen mode.
Differential Revision: https://phabricator.services.mozilla.com/D70931
--HG--
extra : moz-landing-system : lando
This pattern:
```
native nsSize (nsSize);
^
```
Causes a parsing error in `ply` 3.10. This can be easily fixed by removing the space and reformatting to this:
```
native nsSize(nsSize);
```
Differential Revision: https://phabricator.services.mozilla.com/D70711
--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/D68150
--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/D68149
--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/D68148
--HG--
extra : moz-landing-system : lando
- X11 uses MOZ_GTK_DRAG_RESULT_NO_TARGET to state 'no place' for drop. Wayland does not have protocol for it and always return MOZ_GTK_DRAG_RESULT_ERROR.
To emulate X11 behaviour for tab D&D (application/x-moz-tabbrowser-tab mime) don't cancel D&D operation on Wayland for MOZ_GTK_DRAG_RESULT_ERROR
to allow to create a new tab when user drops tab outside the tab bar.
- Provide some additional loging to D&D code.
Differential Revision: https://phabricator.services.mozilla.com/D70333
--HG--
extra : moz-landing-system : lando
This reverts the patch landed in bug 1625857. As it turns out, the
driver version is less significant than the fact that it is a laptop
with dual GPUs. We should continue to give users with this driver
hardware acceleration for optimal performance.
Differential Revision: https://phabricator.services.mozilla.com/D70428
--HG--
extra : moz-landing-system : lando
This isn't technically correct given our current definition for this
result, but it matches the spirit of what we're trying to do here.
Differential Revision: https://phabricator.services.mozilla.com/D69872
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
No functional change here, but this improves readability by using the
Rect and Size structs' operators, rather than breaking out the x/y/width/height
components and doing operations directly.
Depends on D70232
Differential Revision: https://phabricator.services.mozilla.com/D70233
--HG--
extra : moz-landing-system : lando
It doesn't make sense to mix mBounds with GetClientBounds(), as the windows
widget overrides both GetBounds() and GetClientBounds(). So if we're using
GetClientBounds() for the client bounds, we should be using GetBounds() for
the bounds.
Differential Revision: https://phabricator.services.mozilla.com/D70232
--HG--
extra : moz-landing-system : lando
`inputmode=none` means that OSK is closed.
`SetInputContext` doesn't call `DismissOnScreenKeyboard` directly since
`DismissOnScreenKeyboard` has no hack of Firefox VR.
Depends on D68316
Differential Revision: https://phabricator.services.mozilla.com/D68317
--HG--
extra : moz-landing-system : lando
As long as I test on my environment, bug 1226148 isn't fixed. Since native
message queue has high priority, Gecko may check whether focus is changed
before changing focus to another.
So we shouldn't use native message queue for this. It is better to use idle
queue instead.
Depends on D68315
Differential Revision: https://phabricator.services.mozilla.com/D68316
--HG--
extra : moz-landing-system : lando
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
--HG--
extra : moz-landing-system : lando
Current WHATWG spec is that `inputmode` attribute supports non-input element.
I would like to remove input element check for bug 142484 that is
contenteditable support.
Microsoft IME, Google IME and etc refer 1st input scope that they support, so
we will add both input scopes from `type` and `inputmode`.
Depends on D68313
Differential Revision: https://phabricator.services.mozilla.com/D68314
--HG--
extra : moz-landing-system : lando
Current WHATWG spec means that `numeric` is `IS_DIGITS` and `decimal` is
`IS_NUMBER`.
Depends on D68312
Differential Revision: https://phabricator.services.mozilla.com/D68313
--HG--
extra : moz-landing-system : lando
Gecko has duplicated code for input scope support, so I would like to clean up
this.
Differential Revision: https://phabricator.services.mozilla.com/D68312
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
They're supposed to be the same, though right now they are black on white
because only highlight was overridden via prefs.
I'll fix the bugs I found yesterday in a separate bug.
Depends on D69939
Differential Revision: https://phabricator.services.mozilla.com/D69940
--HG--
extra : moz-landing-system : lando
This doesn't change behavior, just makes the color return what we set right now
via prefs in mobile/android/app/mobile.js.
Differential Revision: https://phabricator.services.mozilla.com/D69938
--HG--
extra : moz-landing-system : lando
This patch makes nsIDNSByTypeRecord extend nsIDNSRecord, but implementations
will safely forward the nsIDNSRecord methods to `nullptr`, meaning they will
throw an error when called.
Consumers should try to QI the nsIDNSRecord to nsIDNSByTypeRecord (or any
future types) and use that.
Differential Revision: https://phabricator.services.mozilla.com/D69326
--HG--
extra : moz-landing-system : lando
`inputmode=none` means that OSK is closed.
`SetInputContext` doesn't call `DismissOnScreenKeyboard` directly since
`DismissOnScreenKeyboard` has no hack of Firefox VR.
Depends on D68316
Differential Revision: https://phabricator.services.mozilla.com/D68317
--HG--
extra : moz-landing-system : lando
As long as I test on my environment, bug 1226148 isn't fixed. Since native
message queue has high priority, Gecko may check whether focus is changed
before changing focus to another.
So we shouldn't use native message queue for this. It is better to use idle
queue instead.
Depends on D68315
Differential Revision: https://phabricator.services.mozilla.com/D68316
--HG--
extra : moz-landing-system : lando
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
--HG--
extra : moz-landing-system : lando
Current WHATWG spec is that `inputmode` attribute supports non-input element.
I would like to remove input element check for bug 142484 that is
contenteditable support.
Microsoft IME, Google IME and etc refer 1st input scope that they support, so
we will add both input scopes from `type` and `inputmode`.
Depends on D68313
Differential Revision: https://phabricator.services.mozilla.com/D68314
--HG--
extra : moz-landing-system : lando
Current WHATWG spec means that `numeric` is `IS_DIGITS` and `decimal` is
`IS_NUMBER`.
Depends on D68312
Differential Revision: https://phabricator.services.mozilla.com/D68313
--HG--
extra : moz-landing-system : lando
Gecko has duplicated code for input scope support, so I would like to clean up
this.
Differential Revision: https://phabricator.services.mozilla.com/D68312
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
- Calculate size of wl_buffer as an intersection of widget size and nsWindow bound size.
We can't use wl_buffer bigger than nsWindow bound as it leads to rendering artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D69716
--HG--
extra : moz-landing-system : lando
Changes:
Due to scrollbar and other UI element changes in linux1804 this test was permafailing and was marked as such.
Now that migration has completed for mochitest-plain, re-enable the test with updated pixel count expectations.
Differential Revision: https://phabricator.services.mozilla.com/D66647
--HG--
extra : moz-landing-system : lando
This file has an entry in kWidgetContracts for kNS_SHAREPICKER_CID, but not in
kWidgetCIDs, so there's no implementation. I think this is causing the "Could
not map contract" warning message. We never use the share picker in the content
process, so just remove this.
Differential Revision: https://phabricator.services.mozilla.com/D69146
--HG--
extra : moz-landing-system : lando
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
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
The bugs is reproducible only with all Korean IMEs of Apple only on Catalina.
Until Apple fixes the bug, we should not allow the Korean IMEs to consume
mouse events. (I think that we should keep notifying all mouse events for
backward compatibility.)
Differential Revision: https://phabricator.services.mozilla.com/D67285
--HG--
extra : moz-landing-system : lando
Mutter 3.36 requests exact match of wl_surface/wl_subsurface size so we need to respect
wl_surface size (GtkWidget size) and create a wl_subsurface with the same size.
Differential Revision: https://phabricator.services.mozilla.com/D67137
--HG--
extra : moz-landing-system : lando
On high contrast themes, we avoid using the colors from the author to ensure
contrast.
We allow the border-style though, and that unfortunately means that:
<input type=text style="border: 1px solid black">
Ends up rendering like:
<input type=text style="border-style: solid; border-width: 1px">
Which for a theme with a white background means that we'll render a white
border which users can't see, and is unfortunate.
Hard-code these colors, as using the background color for the light variant
doesn't seem right anyway, and the dark variant was hard-coded already.
These colors are taken from the cocoa widget. You can see the change in colors
with something like:
<input type=text style="border-width: 2px">
For default themes it makes the colors a bit less subtle. But I don't think it
matters all that much in practice since the fallback unthemed border is very
rare on the web these days.
The rendering here is still not great, to be clear (we may want to tweak the
high-contrast heuristics here), but it's way better than invisible borders.
Differential Revision: https://phabricator.services.mozilla.com/D67127
--HG--
extra : moz-landing-system : lando
On high contrast themes, we avoid using the colors from the author to ensure
contrast.
We allow the border-style though, and that unfortunately means that:
<input type=text style="border: 1px solid black">
Ends up rendering like:
<input type=text style="border-style: solid; border-width: 1px">
Which for a theme with a white background means that we'll render a white
border which users can't see, and is unfortunate.
Hard-code these colors, as using the background color for the light variant
doesn't seem right anyway, and the dark variant was hard-coded already.
These colors are taken from the cocoa widget. You can see the change in colors
with something like:
<input type=text style="border-width: 2px">
For default themes it makes the colors a bit less subtle. But I don't think it
matters all that much in practice since the fallback unthemed border is very
rare on the web these days.
The rendering here is still not great, to be clear (we may want to tweak the
high-contrast heuristics here), but it's way better than invisible borders.
Differential Revision: https://phabricator.services.mozilla.com/D67127
--HG--
extra : moz-landing-system : lando
On high contrast themes, we avoid using the colors from the author to ensure
contrast.
We allow the border-style though, and that unfortunately means that:
<input type=text style="border: 1px solid black">
Ends up rendering like:
<input type=text style="border-style: solid; border-width: 1px">
Which for a theme with a white background means that we'll render a white
border which users can't see, and is unfortunate.
Hard-code these colors, as using the background color for the light variant
doesn't seem right anyway, and the dark variant was hard-coded already.
These colors are taken from the cocoa widget. You can see the change in colors
with something like:
<input type=text style="border-width: 2px">
For default themes it makes the colors a bit less subtle. But I don't think it
matters all that much in practice since the fallback unthemed border is very
rare on the web these days.
The rendering here is still not great, to be clear (we may want to tweak the
high-contrast heuristics here), but it's way better than invisible borders.
Differential Revision: https://phabricator.services.mozilla.com/D67127
--HG--
extra : moz-landing-system : lando
`PlaybackState` and `MediaSessionPlaybackState` are actually quite similar, and we don't want to have to many states to confuse reader and do unnecessary tranform between two states. Therefore, replaceing `PlaybackState` with `MediaSessionPlaybackState`.
Differential Revision: https://phabricator.services.mozilla.com/D66342
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
Gecko don't commit composition when software keyboard calls
InputConnection.finishComposingText. It is incompatible with Blink's behaviour.
BaseInputConnection.finishComposingText() implementation is the following.
1. Begin batch edit.
2. Remove all composition span flag.
3. End batch edit.
So if no composition after batch edit is finished, we should commit it on Gecko
to synchronize composition state.
Differential Revision: https://phabricator.services.mozilla.com/D66370
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
This is similar to a change that landed directly into 74. We don't want to
roll-out to these users yet and we don't want to have to think about it every
release.
Differential Revision: https://phabricator.services.mozilla.com/D66453
--HG--
extra : moz-landing-system : lando
Changes:
Due to scrollbar and other UI element changes in linux1804 this test was permafailing and was marked as such.
Now that migration has completed for mochitest-plain, re-enable the test with updated pixel count expectations.
Differential Revision: https://phabricator.services.mozilla.com/D66647
--HG--
extra : moz-landing-system : lando
This patch also tweaks the behavior on Ubuntu Unity slightly to work with the
adaptive workspaces.
Differential Revision: https://phabricator.services.mozilla.com/D66431
--HG--
extra : moz-landing-system : lando
I've left checkbox / radio / range-thumb alone because they don't have borders
on gtk either. We need this for the next patch to fix our test.
In particular, our combination of padding + no border means that
sanityEventUtils tries to hit an <input>, but it hits the anonymous scrollable
element instead, and asserts that it doesn't.
I don't think that test is particularly correct, but implementing
GetWidgetBorder works around it, and seems like the right thing to do anyways.
Differential Revision: https://phabricator.services.mozilla.com/D66240
--HG--
extra : moz-landing-system : lando
I've left checkbox / radio / range-thumb alone because they don't have borders
on gtk either. We need this for the next patch to fix our test.
In particular, our combination of padding + no border means that
sanityEventUtils tries to hit an <input>, but it hits the anonymous scrollable
element instead, and asserts that it doesn't.
I don't think that test is particularly correct, but implementing
GetWidgetBorder works around it, and seems like the right thing to do anyways.
Differential Revision: https://phabricator.services.mozilla.com/D66240
--HG--
extra : moz-landing-system : lando
Bug 1419488 moved AudioSession shutdown to a background thread on Windows 7 because it was leading to shutdown timeouts there. Since then, audio seems to be inspiring timeouts on other versions of Windows as well. This patch extends the Windows 7 work to all versions of Windows.
Bug 1430907 is removing AudioSession from content processes. This is the only place we have seen these crashes but AudioSession is also used in the main and plugin processes, so we want this patch to preempt issues with those processes.
Differential Revision: https://phabricator.services.mozilla.com/D64465
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
`mousemove` event coming from the parent process causes `mouseout` and
`mouseleave` events of the last synthesized `mousemove` in the test. The
reason is, synthesized `mousemove` for tests makes `PresShell` in the content
process record the cursor location, but won't make it `PresShell` in the
parent process do it. Therefore, parent process may synthesize `mousemove`
event for the system cursor position which does not match with the synthesized
mouse location in the content process. Therefore, `:hover` state may be
updated unexpectedly.
This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
came from another process. Then, makes `PresShell::HandleEvent()` ignore
synthesized `mousemove` events coming from another process only when the
recorded mouse location was set by a mouse event synthesized for tests.
Differential Revision: https://phabricator.services.mozilla.com/D65282
--HG--
extra : moz-landing-system : lando
This is very basic, and just uses the button colors. Did this because I thought
that it was going to help me fix one test but it didn't in the end, feel free to
reject, or to tell me to land the cleanup somewhere else :)
Depends on D65674
Differential Revision: https://phabricator.services.mozilla.com/D65675
--HG--
extra : moz-landing-system : lando
Otherwise the rendering of stuff like:
<input type=range style="height: 300px">
Makes no sense. So this is closer to other widgets, and also happens to fix the
only test which is a real regression from non-native widget :)
Depends on D65673
Differential Revision: https://phabricator.services.mozilla.com/D65674
--HG--
extra : moz-landing-system : lando
Chris Peterson
Ciure Andrei
sotaro
Arthur Iakab
Jan Horak
Martin Stransky
Mihai Alexandru Michis
Kris Taeleman
Jeff Muizelaar
Makoto Kato
Harry Twyford
Ryan Pauls
alwu
Haik Aftandilian
Kristen Wright
Bogdan Tara
Cameron McCormack
Narcis Beleuzu
Dylan Roeh
Andrew Osmond
Emilio Cobos Álvarez
James Willcox
Cosmin Sabou
Mike Hommey
Kartikaya Gupta
nicolaspacheco
Mike de Boer
Randall E. Barker
Andreas Farre
Valentin Gosu
Mike Conley
Xidorn Quan
Edgar Chen
Timothy Nikkel
Brian Grinstead
Sylvestre Ledru
Botond Ballo
Oana Pop Rus
jayati
Edwin Takahashi
Andrew McCreight
sonakshi
Razvan Maries
Christoph Walcher
André Bargull
Stephen A Pohl
Masayuki Nakano
Dorel Luca
Simon Giesecke
Jonathan Kew
Eric Rahm
Michael
Marc Streckfuss
Brindusan Cristian
Chris Fronk
Kenny Levinsen
Coroiu Cristina
Jessie Bonisteel
Andreea Pavel
Marco Zehe
Boris Zbarsky
David Parks
Mark Banner