This is a very first iteration of about:processes, so that people who actually need the tool can start using it immediately and provide feedback.
Differential Revision: https://phabricator.services.mozilla.com/D72617
The only caveat here is that gfxVars are not atomic, but multiple threads can
query DWM status. To solve this, changes to the var are mirrored into an atomic
and that is read instead.
DWM status changes are indicated by Windows via a window message. We use that
window message to cause the update to propagate
Differential Revision: https://phabricator.services.mozilla.com/D73743
Currently, There are multiple places that call the Win32 APIs for DWM status.
Once Win32k lockdown is enabled, this API will be unavailable and will need
to be remoted. This new function will be made to work in both parent and
content processes, and therefore all DWM queries must be directed to it.
Also, some minor cleanup because... Why not?
Differential Revision: https://phabricator.services.mozilla.com/D73742
Chrome and Safari ignore pinch zooming while a select dropdown is open.
The other option is to close the dropdown, which is what we already do if you two finger scroll on the touchpad. Chrome and Safari also ignoring two finger scrolling while a select dropdown is open.
Differential Revision: https://phabricator.services.mozilla.com/D73539
This is already the case for real input events since that's how they
arrive from APZ, and we are no longer changing the coordinates at
the process boundary.
For synthesized events, a future patch will add layout-to-visual
converions to code that sets mRefPoint as appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D68917
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
The old code didn't handle content prevent defaulting the input.
The pinch gesture code doesn't seem to fully work properly, it will allow a little pinch zooming before halting it if content is prevent defaulting it. Not sure what is up yet.
Differential Revision: https://phabricator.services.mozilla.com/D73220
We can't just get pinch events, we need to handle both.
This state machine code is basically copied from Chrome's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D71307
I had to mess with the refcounting of Display (and hence destructors) because we create a NewRunnableMethod inside Display that holds a pointer to |this|. There are versions of NewRunnableMethod that don't take a ref but I'm not sure of the lifetime of Display, so easier to just take a ref since several of the subclasses are already refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D71303
Rounding to nearest means that if you get a fractional pixel like 10.2px
you round down to 10, which means that the popup text may wrap
undesirably. I've seen this a bunch lately.
Differential Revision: https://phabricator.services.mozilla.com/D73393
CondVar already calls `AUTO_PROFILER_THREAD_SLEEP`, which shouldn't be called recursively.
mozilla::Monitor also uses CondVar, so it shouldn't be surrounded by `AUTO_PROFILER_THREAD_SLEEP` either.
Depends on D72850
Differential Revision: https://phabricator.services.mozilla.com/D72851
As bug 1544435, we blocked wbload.dll from being loaded in content processes.
Because that modules is injected via `user32!RegisterUserApiHook` and Windows
keeps trying to load hooking modules even if the previous attempt has failed,
blocking wbload.dll caused repetitive loading attempts in the tab process,
resulting in bad rendering performance.
This patch is to mitigate that performance issue by not calling `OpenThemeData`,
which is one of the entrypoints triggering user api hook, if the previous call
has failed. With this patch, performance is still slower than with the default
theme. We will seek out a long-term solution to solve the issue.
Differential Revision: https://phabricator.services.mozilla.com/D73344
Actually we emulate key event (down, press and up) from replace transaction of
`Editable`. When dispatching key press, we always update current caret position.
Most situations is the following.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive merged text/selection change result by 1. and 2.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
correct position now.
5. Dispatch keypress with correct position.
When this issue occurs, the following situation occurs.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive text/selection change result of 1.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
old position now.
5. Dispatch another keypress with old position.
6. Receive text/selection change result of 2.
7. Receive text/selection change result of 5.
So when dispatching key press, we shouldn't always update selection if unnecessary.
Because selection range is already often set before dispatching key press.
Differential Revision: https://phabricator.services.mozilla.com/D71179
Both `nsAppShell::ProcessNextNativeEvent()` and `MessagePumpForUI::WaitForWork()` have a `PROFILER_AUTO_THREAD_SLEEP` surrounding the `mozilla::widget::WinUtils::WaitForMessage()` call.
However inside `WaitForMessage()` the call to `PeekMessageW()` may trigger a sequence of events (because the system delivers pending messages) that end in the initialization of a new thread, which invokes `ReentrantMonitor::Wait()` where there is a `PROFILER_AUTO_THREAD_SLEEP`.
To avoid this recursion, this patch moves `PROFILER_AUTO_THREAD_SLEEP` from both callers into `WaitForMessage()` to only enclose the actual potentially-sleeping operation `::MsgWaitForMultipleObjectsEx()`.
Differential Revision: https://phabricator.services.mozilla.com/D72850
This is already the case for real input events since that's how they
arrive from APZ, and we are no longer changing the coordinates at
the process boundary.
For synthesized events, a future patch will add layout-to-visual
converions to code that sets mRefPoint as appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D68917
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
The original workaround given by Microsoft was both WS_EX_TRANSPARENT and WS_EX_LAYERED. In bug 1627505 we tried to just add WS_EX_LAYERED because it was all that was needed to fix that bug and we hoped it wouldn't re-introduce the blank window problem. But it did. So we may as well go with both flags as recommended by Microsoft.
Differential Revision: https://phabricator.services.mozilla.com/D72598
Mozcontainer is accessed from various threads - Main/Compositor/Renderer - which causes races
when wayland surfaces are created/deleted/updated so we need to control it.
Differential Revision: https://phabricator.services.mozilla.com/D71737
On older machines it creates a blank window and we only need the pref to direct manipulation (which hasn't landed yet and will be preffed off by default when it lands).
Differential Revision: https://phabricator.services.mozilla.com/D72283
On older machines it creates a blank window and we only need the pref to direct manipulation (which hasn't landed yet and will be preffed off by default when it lands).
Differential Revision: https://phabricator.services.mozilla.com/D72283
This is used by platforms with overlay scrollbars, only in order to
reserve enough space for the chevron of the `<select>` element.
So our general min-widget-size, which is the same as for scrollbars
works.
Differential Revision: https://phabricator.services.mozilla.com/D71825
Mozcontainer is accessed from various threads - Main/Compositor/Renderer - which causes races
when wayland surfaces are created/deleted/updated so we need to control it.
Differential Revision: https://phabricator.services.mozilla.com/D71737
Change the nsMacShellService::SetDesktopBackground() implementation (specifically code in the OnStateChange handler) to use the Apple setDesktopImageURL API instead of Apple Events to allow the "Set As Desktop Background..." context menu option to work again.
Alternatively, to allow the AppleEvent-base implementation to work again, Firefox could be signed with the com.apple.security.automation.apple-events entitlement but this would also require the user to grant Firefox permission to control Finder. setDesktopImageURL requires Mac OS 10.6 or newer and hence was not an option originally.
The implementation only changes the background of the focused screen in the current workspace (which matches the behavior of Safari).
Differential Revision: https://phabricator.services.mozilla.com/D71426
This is used by platforms with overlay scrollbars, only in order to
reserve enough space for the chevron of the `<select>` element.
So our general min-widget-size, which is the same as for scrollbars
works.
Differential Revision: https://phabricator.services.mozilla.com/D71825
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
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
Dorel Luca
Jean-Yves Avenard
Mike Hommey
David Teller
Chris Martin
Jeff Muizelaar
Martin Stransky
Narcis Beleuzu
Bob Owen
sotaro
Mihai Alexandru Michis
Markus Stange
Timothy Nikkel
Botond Ballo
Ian Moody
Razvan Maries
Kartikaya Gupta
Stephen A Pohl
Emilio Cobos Álvarez
Cosmin Sabou
Gerald Squelart
Jonathan Watt
Toshihito Kikuchi
Mike de Boer
Makoto Kato
Simon Giesecke
Csoregi Natalia
Sylvestre Ledru
Chun-Min Chang
Tom Schuster
Brindusan Cristian
Noemi Erli
Bogdan Tara
Haik Aftandilian
Jan Horak
Robert Mader
Chris Peterson
Ciure Andrei
Arthur Iakab
Kris Taeleman
Harry Twyford
Ryan Pauls
alwu
Kristen Wright
Cameron McCormack
Dylan Roeh
Andrew Osmond
James Willcox
nicolaspacheco
Randall E. Barker
Andreas Farre