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
Mihai Alexandru Michis
Jan Horak
sotaro
Kris Taeleman
Jeff Muizelaar
Makoto Kato
Martin Stransky
Harry Twyford
Ryan Pauls
alwu
Haik Aftandilian
Kristen Wright
Bogdan Tara
Cameron McCormack
Narcis Beleuzu
Dylan Roeh
Chris Peterson
Andrew Osmond
Emilio Cobos Álvarez
James Willcox
Cosmin Sabou
Mike Hommey
Kartikaya Gupta
nicolaspacheco
Mike de Boer
Randall E. Barker
Andreas Farre