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
