Otherwise Chromium gets confused when pasting (Signal is an Electron
application).
I need to dig a bit more, but this doesn't prevent the fix for
bug 1774285 from working, and fixes the issue here.
It's probably a Chromium bug that this doesn't work tho since,
as mentioned in comment 0, it works on other Windows applications.
Differential Revision: https://phabricator.services.mozilla.com/D160808
DONTBUILD because this is just whitespace cleanup.
I found the files to fix up here using this command:
grep -r ' ' * 2>/dev/null | grep -v "other-licenses" | grep "idl:"
I replaced the tab characters with however many spaces seemed consistent with
the indentation in the surrounding code (and did some minor space-indentation
cleanup in contextual lines to preserve alignment, in a few cases).
Differential Revision: https://phabricator.services.mozilla.com/D160577
This prevents a11y from getting instantiated shortly after clipboard paste, in
order to prevent hangs with the Windows 11 suggested actions feature.
When combined with the previous patch, the behavior is the following:
* For users with a11y already-enabled:
* No hang (due to clipboard flush).
* Quick actions menu is positioned at selection offset.
* For users with a11y disabled (most):
* No hang (due to no a11y instantiation + clipboard flush).
* Quick actions menu is positioned at pointer (cursor) offset.
Co-Authored-By: Emilio Cobos Álvarez <emilio@crisal.io>
Differential Revision: https://phabricator.services.mozilla.com/D160652
Depends on D160646
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
When compositor session exists, gfxConfig is already initialized.
If first AppWindow is destroyed in nsAppShellService::JustCreateTopWindow() because of error, the first window could be destroyed before calling gfxConfig::Init(). gfxConfig::Init() is called from gfxPlatform::GetPlatform(). gfxPlatform::GetPlatform() is called just before creating compositor by nsBaseWidget::CreateCompositor()
Differential Revision: https://phabricator.services.mozilla.com/D160453
In bug 1772839 we were seeing a large number of crashes due to
encountering a webrender error after exhausting all fallback
configurations. At least in some cases, this was due to the compositor
being resumed with an Android Surface that was already in an abandoned
state, meaning we can never succeed in creating an EGL Surface.
We added a check for this condition, and a workaround, to the
GeckoView java code. However, we are still seeing crash reports
matching this signature. To help determine whether these are also due
to the Surface being abandoned, or due to some other reason, this
patch adds a deliberate crash much earlier in the pipeline if we
detect an abandoned Surface.
Differential Revision: https://phabricator.services.mozilla.com/D160042
Ensure that when we evaluate the downloadable blocklist, we actually
only use the downloadable blocklist. We should not include any platform
specific checks in these prefs, as it causes confusion about why the
prefs were set in the first place. Allowlisted features should be
ignored when evaluating the downloadable blocklist; if we wish to
override the ALLOW/ALLOW_QUALIFIED/DENIED statuses, we should use OK or
BLOCKED_DEVICE or similar instead.
This caused allowlisted features (like WebRender) to be taken away from
users in the most recent nightly.
Differential Revision: https://phabricator.services.mozilla.com/D160408
If we get via OnFrameChanging, we compute a new sizemode, but never store it on
the widget, yet we notify that it has changed.
We were relying on a call to mWindow->SetSizeMode from the widget delegate
which I removed in:
c9785cd100
Instead, call EnsureSizeMode to make sure we already have the right sizemode
when notifying our listener.
Differential Revision: https://phabricator.services.mozilla.com/D160365
If we get via OnFrameChanging, we compute a new sizemode, but never store it on
the widget, yet we notify that it has changed.
We were relying on a call to mWindow->SetSizeMode from the widget delegate
which I removed in:
c9785cd100
Instead, call EnsureSizeMode to make sure we already have the right sizemode
when notifying our listener.
Differential Revision: https://phabricator.services.mozilla.com/D160365
Ensure that when we evaluate the downloadable blocklist, we actually
only use the downloadable blocklist. We should not include any platform
specific checks in these prefs, as it causes confusion about why the
prefs were set in the first place. Allowlisted features should be
ignored when evaluating the downloadable blocklist; if we wish to
override the ALLOW/ALLOW_QUALIFIED/DENIED statuses, we should use OK or
BLOCKED_DEVICE or similar instead.
This caused allowlisted features (like WebRender) to be taken away from
users in the most recent nightly.
Differential Revision: https://phabricator.services.mozilla.com/D160408
We have added a number of new status codes, for the allowlist and new
errors that were not previously handled by the code managing the gfx
blocklist prefs. We also now iterate over the range of features instead
of manually listing the features, as some were missed during previous
additions.
Differential Revision: https://phabricator.services.mozilla.com/D160053
Some users may keep disabling TSF while we were improving TSF implementation due
to avoiding some bugs.
Currently, we don't test IMM handler. Therefore, I think that we should rename
the pref and make users run well-tested path to handle IME.
Depends on D159818
Differential Revision: https://phabricator.services.mozilla.com/D159819
This pref is used for behavior check of how newer TSF behave without IMC.
Therefore, this shouldn't be used by users. However, like bug 1367692 and
bug 1409155, this may be useful when we meet a critical bug of old IME in
newer Windows. Thus we should keep this pref.
Depends on D159817
Differential Revision: https://phabricator.services.mozilla.com/D159818
It's introduced in bug 1367692 to make it possible to test the bug of old
MS-IME on Windows 10 with later versions. Now, the bug and the old versions
have gone. Therefore, we don't need this pref anymore.
Depends on D159816
Differential Revision: https://phabricator.services.mozilla.com/D159817
We haven't seen this with Adwaita because it uses dark tooltips in both
light and dark mode, so stuff kinda worked out in the end.
Differential Revision: https://phabricator.services.mozilla.com/D159966
I don't know understand how to recursively run initializing `mContentForTSF`
with dispatching a query content event because it may flush pending layout,
but the notifications will be sent in next tick by `IMEContentObserver`.
However, anyway, it rarely occurs in some environments.
Therefore, this patch makes `TSFTextStore` defer notifying TSF until finishing
initializing the content/selection cache to avoid to emplace `Maybe` twice.
Additionally, with adding a call of `.reset()` and `MOZ_DIAGNOSTIC_ASSERT`,
this patch prevents the crash in the release channel.
Depends on D159660
Differential Revision: https://phabricator.services.mozilla.com/D159661
It means that `TSFTextStore` should defer notifying TSF of content/layout
changes until receiving a reply from `ContentCacheInParent` or
`IMEContentObserver`. For making it explain by itself, this patch rename it.
Differential Revision: https://phabricator.services.mozilla.com/D159660
This fixes ESLint issues raised by mozilla/valid-services-properties.
This also changes follow-on issues to use Services.appinfo rather than getService.
Differential Revision: https://phabricator.services.mozilla.com/D159461
Updating mBounds.Size() without calling WindowResized leaves the window
temporarily in a state where inner and outer sizes are out of sync.
BrowserParent::UpdatePosition should call BrowserParent::UpdateDimension
with the size during the last update, rather than the current window
size. There is an edge case where a call can happen between a resize and
its reflow, and a second resize could prevent the reflow from changing
the frame loader size, leaving the BrowserChild with an outdated outer
size.
Differential Revision: https://phabricator.services.mozilla.com/D158343
The color picker currently appears in a "default" location upon opening, which seems to be for my machines the bottom left of the screen or another screen entirely depending on where my Firefox instance was opened. It seems like the best way to fix this is to actually create the color picker where you have clicked for it. Since `nsColorPanel` ultimately inherits from `nsWindow`, we can do this while opening by calling our `setFrameOrigin` method with the current pointer location.
Differential Revision: https://phabricator.services.mozilla.com/D157710
The first size-allocate is likely (or guaranteed) to be of the size at
the time of the first NativeShow(true) call. Any resize between show and
the first size-allocate will be accounted for in a second size-allocate
signal. If we update and dispatch the window size at the beginning of
such a resize, we end up reverting back to previous size from the first
size-allocate signal before dispatching the size for the resize again
from the second size-allocate signal.
Differential Revision: https://phabricator.services.mozilla.com/D158580
This commit introduces a MathML preference for the legacy implementation
of the lquote/rquote attributes, and disable it by default. This feature
is not implemented in Chromium or WebKit, not part of MathML Core and
Firefox's implementation has issues (e.g. bugs 787215 and 1108608).
Differential Revision: https://phabricator.services.mozilla.com/D158479
Non-malicious IME (and text services) must not require private things in URL,
such as username and password, query data and reference in the document.
Therefore, we should omit them from URI exposed from our native IME handlers in
any platforms.
Differential Revision: https://phabricator.services.mozilla.com/D158734
Fire scrollend events to the document and elements if
apz.scrollend.event.enabled is set. If the guarding preference is not set,
fire a chrome-only event to preserve the pre-existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D157652
The previous patch made me realize that we have this widget-imposed size
for color controls which doesn't match any other browser. This patch
removes it.
I don't feel strongly whether we should land this other than "it matches
other browsers, and removes a special case from Gecko". Behavior might
be simpler to understand for authors this way.
Differential Revision: https://phabricator.services.mozilla.com/D158620
The XUL behavior in nsBox.cpp is fairly different to what the non-XUL
layout code paths do. In particular, canOverride=false means that the
min-{width,height} properties cannot go under the min widget size of the
widget, but that doesn't mean that intrinsic sizes don't affect the
final size of the widget.
This is very visible if you turn on flex emulation on Windows or macOS,
where the toolbar has an appearance that returns
width=0,height=N,canOverride=false.
With flex emulation we'd collapse the item to be zero-width, which is
not good at all.
The good thing is that this is no longer exposed to the web
(non-native-theme always returns canOverride=true), and our front-end
code doesn't seem to rely on this, so we can just remove support for
canOverride=false.
Differential Revision: https://phabricator.services.mozilla.com/D158608
Due to https://gitlab.gnome.org/GNOME/gtk/-/issues/4437 / Bug 1710344 we need to add popup window position to D&D coordinates provided by Gtk.
In this patch always use GdkWindow derived from mShell which is attached to parent window.
Don't use GdkWindow of mContainer which is nested child window and it's positioned at 0,0.
Differential Revision: https://phabricator.services.mozilla.com/D158653
This element had a really weird dependency on the order of the command
events from the menuitems and the button which broke in bug 1790920.
Instead of keeping this element as a XULButtonElement, have a separate
button and popup. That's simpler and less prone to breakage, and allows
to get rid of special cases in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D158438
This element had a really weird dependency on the order of the command
events from the menuitems and the button which broke in bug 1790920.
Instead of keeping this element as a XULButtonElement, have a separate
button and popup. That's simpler and less prone to breakage, and allows
to get rid of special cases in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D158438
This means that the change has a risk of compatibility with IME, but from the
other point of view, we already behave differently from the other browsers
in native IME API handler level too.
Differential Revision: https://phabricator.services.mozilla.com/D158107
The crash tracked in bug 1792767 is caused by uninitialized member of
`TSFTextStore`. Therefore, it runs the cleaning up the TSF objects at
setting focus to new `TSFTextStore`, but MS-IME didn't grab the necessary
objects and thus, the crash occurs.
Differential Revision: https://phabricator.services.mozilla.com/D158311
Now, `inputmode` attribute (`inputMode` in the DOM interface) is a global
attribute for `contenteditable`. Therefore, `Input` is not necessary and
`Inputmode` should be `InputMode`.
Differential Revision: https://phabricator.services.mozilla.com/D158244
`TSFTextStore` needs to expose the document URL for supporting new feature
of Windows 11 22H2 update. Therefore, the `InputContext` should have the
document URL.
Differential Revision: https://phabricator.services.mozilla.com/D157893
The rounding error workaround is broken - on recent Gtk it produces needless stream of move-to-rect callback.
It's because we move popup of GDK_WINDOW_TYPE_HINT_POPUP_MENU type and this is positioned by Gtk by move-to-rect even if gtk_window_move() is called.
But it looks like we don't need this workaround any more due to recent fixes (1786525, 1786588, 1786525, 1765714).
Differential Revision: https://phabricator.services.mozilla.com/D158217
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
`TSFTextStore` needs to expose the document URL for supporting new feature
of Windows 11 22H2 update. Therefore, the `InputContext` should have the
document URL.
Differential Revision: https://phabricator.services.mozilla.com/D157893
We can't use move-to-rect if there are more parents of wl_subsurface popups types.
It's because wl_subsurface is ignored by xgd_popup (created by move-to-rect) so our popup scenario:
toplevel -> xgd_popup(1) -> wl_subsurface(2) -> xgd_popup(3)
looks for Wayland compositor as:
toplevel -> xgd_popup(1) -> xgd_popup(3)
If xgd_popup(1) and xgd_popup(3) are not adjacent then move-to-rect applied to xgd_popup(3) fails and we get missing popup.
Depends on D158120
Differential Revision: https://phabricator.services.mozilla.com/D158121
Wne context menu is positioned by plain move, we need relative popup coordinates. So calculate them according to context menu parent popup.
Differential Revision: https://phabricator.services.mozilla.com/D158120
There are some suspect crashes around Wayland SHM interface so let's make sure we have valid shm handle before we pass it to Wayland.
It covers the 'It can't happen' scenario which tends to happen despite of all premises.
Differential Revision: https://phabricator.services.mozilla.com/D157975
When figuring out menuhover background, make sure not to come up with
the exact same color as the menu background. This ensures we also try
gradients / background-images before giving up.
This is only an issue with the dark theme in this case, because
otherwise we use native drawing.
Differential Revision: https://phabricator.services.mozilla.com/D157963
move-to-rect offset does not work realibly in mutter and can lead to invisible window.
It's used mainly for tooltips so let's skip it for now.
Differential Revision: https://phabricator.services.mozilla.com/D157926
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
Map/Unmap signals creates and deletes mContainer wayland surface and EGL window.
As we need to call the handlers in correct order (mContainer::map -> nsWindow::map and nsWindow::unmap -> mContainer::unmap)
connect the signals to mContainer widget and call mContainer::unmap from nsWindow::unmap.
Then nsWindow::unmap can update compositor before wl_surface/EGL window is released by mContainer.
Differential Revision: https://phabricator.services.mozilla.com/D157357
nsTransferable was modified to prevent disk leakings when copying data
in private browsing mode with Bug 1123480.
However, the context is nullptr when it is initialized, so it still
leaks if PBM is enabled by default.
Our solution is to check the browser.privatebrowsing.autostart in this
condition.
Differential Revision: https://phabricator.services.mozilla.com/D157800
The android magnifier widget does not work when using our
SurfaceControl rendering path, as we no longer render in to the
Surface provided by the SurfaceView, but instead into a child Surface
we have created and attached the SurfaceControl.
To fix this, we create a SurfaceView subclass, MagnifiableSurfaceView,
which allows us to set an override Surface to be used by the
magnifier. This class works by overriding getHolder() to return a
custom SurfaceHolder, which returns our override Surface rather than
the default one when called by the Magnifier class.
Depends on D157308
Differential Revision: https://phabricator.services.mozilla.com/D157309
In order to fix the magnifier widget being broken, the previous patch
in this bug added a mechanism to disable and enable the SurfaceControl
rendering path. This caused some glitches to occur, so we removed the
calls to that code in bug 1783542, but the code remained.
As we now have an alternative solution to fix the magnifier widget, we
no longer require this code. This patch therefore reverts the original
patch, to lead the way for the new solution in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D157308
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
Map/Unmap signals creates and deletes mContainer wayland surface and EGL window.
As we need to call the handlers in correct order (mContainer::map -> nsWindow::map and nsWindow::unmap -> mContainer::unmap)
connect the signals to mContainer widget and call mContainer::unmap from nsWindow::unmap.
Then nsWindow::unmap can update compositor before wl_surface/EGL window is released by mContainer.
Differential Revision: https://phabricator.services.mozilla.com/D157357
When entering fullscreen and saving the original position of a window,
also save the position to which it was moved.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410