The underlying issue here is an invalidation bug with XUL layout. When a
popup opens, we try to lay it out at full size, then post a reflow
callback to constrain it.
There's an intermediate step there where the popup might remain at full
size, and the constraining operates directly on mRect, which isn't quite
sound and doesn't update the scrollport of descendants.
Make nsMenuPopupFrame inherit from nsBlockFrame instead, doing
potentially two layout passes when constrained.
This fixes the issue at hand, and removes XUL layout from menu popups,
so it's a win-win.
To make reasoning about it a bit easier, factor out a bunch of the XUL
positioning code to be const. The mutation of mRect etc which was going
on otherwise was pretty hard to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D170368
At least on my system you can get on an state where XDG_CURRENT_DESKTOP is set
to the empty string (I think this comes from sddm when launching a legacy
WM).
Found this while trying to repro bug 1820542. Unclear if this is enough to fix
the issues in comment 0 but locally it's enough to fix fvwm detection here.
Differential Revision: https://phabricator.services.mozilla.com/D172568
The source node is typically a text node, and it may be editable by
`contenteditable` or `designMode`. In that case, the source node may be removed
during the DnD session even without tricky JS code. In this case, Blink and
WebKit updates the source node to dispatch `dragend` to the editing host.
This behavior does not conform to the standardized DnD behavior, however,
this is reasonable for editor apps which want to listen to events in editing
host or window/document for footprint and/or performance reason. Therefore,
we should follow their behavior.
Differential Revision: https://phabricator.services.mozilla.com/D172091
This bug implements and opens window.print() for Android in Nightly.
Adds "GeckoView:DotPrintRequest" and "GeckoView:DotPrintFinish" events.
GeckoView:DotPrintRequest requests a PDF of the current window.print
page for Android to print. GeckoView:DotPrintFinish releases the static
browser clone created by window.print. PDF generation was additionally
adjusted to get the expected canonical browser context when printing
iframes.
Differential Revision: https://phabricator.services.mozilla.com/D171159
This is semantically similar to the existing available() method, however will
not block, and doesn't need to do the work to actually determine the number of
available bytes.
As part of this patch, I also fixed one available() implementation which was
incorrectly throwing NS_BASE_STREAM_WOULD_BLOCK.
Differential Revision: https://phabricator.services.mozilla.com/D170697
The `mHandledResult` is set in the ctor of APZEventResult based on an incoming
TargetConfirmationFlags, we shouldn't clobber the original `mHandledResult` when
we set `eConsumeDoDefault` for pan events.
Note that we should probably do the same thing for other
SetStatusAsConsumeDoDefault call sites basically, but for now I'd like to make
this change as mimumum as possible.
Differential Revision: https://phabricator.services.mozilla.com/D172525
If we queue the SwipeEventQueue in the case where the corresponding pan-start
event was consumed by the root content APZC, we wait for a response from the
content. And if the consumed pan-start event scrolled to the edge of the scroll
container and if the new scrolled position has been reached to the content
process before we tell whether the scroll position of the scroll container is
at the edge [1], we report it back to the SwipeTracker as the event should be
an event as a start of swipe navigation gestures. Thus, once after we got a
pan-end event, we trigger a swipe navigation. It results timeouts on a test case
waiting for an APZ:TransformEnd notification which never happens due to the page
navigation.
There's also a similar race condition where a pan-start event was consumed by a
non-root content APZC. But I haven't been able to reproduce the similar case
manually so I just filed bug 1821967 for the race and I am not going to handle
the race here. Note that I haven't been able to reproduce the original race
condition manually either though.
[1] https://searchfox.org/mozilla-central/rev/2f9a79d1c4ae7090cf50d93be86ba9dc2767a733/dom/events/EventStateManager.cpp#3727-3728
Differential Revision: https://phabricator.services.mozilla.com/D172391
The read-loop in OnDataAvailable is needlessly baroque and uses a very
strange dialect of Hungarian notation. Factor out the zero-element case
for simplicity (of explication, if nothing else), and add justificatory
comments as appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D171001
This renames nsMacCursorManager to MOZDynamicCursor and makes it implement NSCursor.
We also install a cursor rect which covers the entire ChildView and which refers
to the MOZDynamicCursor singleton.
With the help of the cursor rect, the -[NSCursor set] implementation is now called
at the right times.
Here's a profile which contains the stacks under which -[MOZDynamicCursor set]
is now called: https://share.firefox.dev/3yEXLsC
Differential Revision: https://phabricator.services.mozilla.com/D172484
Happy code deletion day!
nsMacCursor was used so that animated cursors could be treated like non-animated cursors.
But we don't have animated cursors anymore! Nothing calls -[nsMacCursor cursorWithFrames:type:].
Depends on D172479
Differential Revision: https://phabricator.services.mozilla.com/D172480
Implemented the prefers-reduced-transparency media query for all
platforms.
Windows and Mac have specific settings which are used, others (Android
and Linux/GTK) have it enabled if prefers-reduced-motion is also enabled
as there is no dedicated setting to check.
Locked behind new pref `layout.css.prefers-reduced-transparency.enabled`,
off by default always for now.
Also added new WPT tests (none previously).
Demo video: https://goose.icu/firefox_prt.mp4
Test page: https://goose.icu/prefers-reduced-transparency
Differential Revision: https://phabricator.services.mozilla.com/D172424
For some reason, the frame passed to windowWillUseStandardFrame:defaultFrame:
is not reliably a frame representing the maximum frame for the window's
screen. This is possibly a bug in Cocoa. To compensate, we return the
frame of the window's screen and rely upon the Cocoa caller to shrink it
enough to fit between the menubar and the dock (which does seem to work).
Differential Revision: https://phabricator.services.mozilla.com/D172167
The lack of the flush is one of the causes of the test timeouts. Without the
flush, the content in question is not overscrollable, thus a swipe gesture
triggers a navigation back to the previous content rather than overscrolling.
Differential Revision: https://phabricator.services.mozilla.com/D172170
Without this change, it is possible for a macOS window in maximized state
to be unable to return to normal state via a SetSizeMode call. This means
that a JS call to "window.restore()" has no effect. This patch fixes that
case by detecting the failure and resizing to a slightly smaller size
that qualifies for the normal state.
This also implements windowWillUseStandardFrame:defaultFrame: in a trivial
way, which seems to be necessary for the window.zoomed property to return
YES only when the window frame fills the screen.
This is very difficult to test intentionally with a window that is
maximized and has forgotten its Cocoa-tracked "user state". But that state
is reached in our test harness and this will get us out of it. It has the
desirable(?) side effect of making the macOS menu bar action Window->Zoom
do something with a window that is already maximized to the screen.
Differential Revision: https://phabricator.services.mozilla.com/D171831
Also use a relatively bigger "apz.overscroll.damping" value to avoid the situation
where the overscroll gutter has been already restored when we observe
"APZ:TransformEnd".
Differential Revision: https://phabricator.services.mozilla.com/D171938
After landing bug 1819466, we started seeing a consistent uptick in
crashes on older drivers using WebGL. Given the limited population on
older drivers on nightly, this is a sign we are unable to ship EGL on
these drivers without further investigation.
Differential Revision: https://phabricator.services.mozilla.com/D171915
Without this change, it is possible for a macOS window in maximized state
to be unable to return to normal state via a SetSizeMode call. This means
that a JS call to "window.restore()" has no effect. This patch fixes that
case by detecting the failure and resizing to a slightly smaller size
that qualifies for the normal state.
This is very difficult to test intentionally with a window that is
maximized and has forgotten its Cocoa-tracked "user state". But that state
is reached in our test harness and this will get us out of it. It has the
desirable(?) side effect of making the macOS menu bar action Window->Zoom
do something with a window that is already maximized to the screen.
Differential Revision: https://phabricator.services.mozilla.com/D171831
The browser mochitest in this change causes a timeout without this fix since
the overscroll gutter gets stuck thus we will never get "APZ:TransformEnd".
Differential Revision: https://phabricator.services.mozilla.com/D171421
This patch attempts to make nsCocoaWindow transitions (fullscreen,
windowed, minimize, zoom) atomic operations that can't be disrupted by
user action or by programmatic triggers. To accomplish this, it defines a
transition queue which ensures that when a transition is submitted, it is
always run to completion before another transition is started. Native
transitions execute asynchronously, and emulated ones execute
synchronously.
Additionally, this patch adds intermediary transitions to handle
programmatic transitions which aren't allowed by macOS, which include:
1) Attempting to minimize a fullscreen window will first transition to
windowed state.
2) Any transition on a minimized window will first transition to windowed
state.
A later part of this patch stack tests this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D166450
That code only runs in the parent process by design. And we use
infallible new so there's no need to release-assert that allocation
succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D171579
We are seeing a large uptick in crashes across all channels with the
NVIDIA binary drivers, including 470, 510, 515, 520, and 525. This
crash is tracked in bug 1788573.
Differential Revision: https://phabricator.services.mozilla.com/D171512
This patch attempts to make nsCocoaWindow transitions (fullscreen,
windowed, minimize, zoom) atomic operations that can't be disrupted by
user action or by programmatic triggers. To accomplish this, it defines a
transition queue which ensures that when a transition is submitted, it is
always run to completion before another transition is started. Native
transitions execute asynchronously, and emulated ones execute
synchronously.
Additionally, this patch adds intermediary transitions to handle
programmatic transitions which aren't allowed by macOS, which include:
1) Attempting to minimize a fullscreen window will first transition to
windowed state.
2) Any transition on a minimized window will first transition to windowed
state.
A later part of this patch stack tests this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D166450
TestWinDND.cpp was disabled when libxul became a separate library which
could no longer be used by cppunittests.
Add a few shims to turn it into a gtest instead, and hook it back up.
Differential Revision: https://phabricator.services.mozilla.com/D171280
This patch adds two new attributes to the window's `html` element, `windowclass` and `windowname`, to allow directly controlling the window's class hints on Xorg/Wayland (`res_class` and `res_name`) from the chrome/JS code. When they are set, values are used as class hints for their window. When they are not set, the current behavior of determining `res_class` and `res_name` (using `gdk_get_program_class` for `res_class` and parsing `windowtype` for `res_name`) is preserved.
Changes in `widget/nsIWidget.h` and `widget/nsBaseWidget.h` are only interface changes so that `setWindowClass` can accept three attributes. Although this patch does not affect Windows, `widget/windows/nsWindow.h` and `widget/windows/nsWindow.cpp` have been updated to comply with the new interface. `xpfe/appshell/AppWindow.cpp` has been updated to get the additional attributes and call `setWindowClass` with them. The main changes are in `widget/gtk/nsWindow.h` and `widget/gtk/nsWindow.cpp`.
Differential Revision: https://phabricator.services.mozilla.com/D169720
This does not reduce the number of threads we end up using in these
cases, but simplifies the complex implementation substantially by
relying on the idle thread lifetime management logic from nsThreadPool.
The nsISerialEventTarget implementation is maintained by wrapping the
nsThreadPool with a TaskQueue.
As a result of using these more reliable backing implementations, the
type is now also safe to use from any thread, rather than requiring
dispatches to all occur from the creator thread.
Unfortunately, this required some changes to the
UntrustedModulesProcessor, which was relying on the ability to fetch the
PRThread* (and from that the HANDLE) from the lazy thread in order to
perform priority changes on it. This was fixed by using a
nsIThreadPoolListener to watch the thread being created and destroyed,
and manually record a HANDLE to the thread which can be used for these
priority changes.
Differential Revision: https://phabricator.services.mozilla.com/D168017
TestWinDND.cpp was disabled when libxul became a separate library which
could no longer be used by cppunittests.
Add a few shims to turn it into a gtest instead, and hook it back up.
Differential Revision: https://phabricator.services.mozilla.com/D171280
`ContentEventHandler` may not replace open/close tags of inline elements and
close tags of block elements with a line break etc. Therefore, one offset may
mean multiple points in the DOM tree. From the DOM tree point of view, every
DOM point may have different meaning and styles. Therefore, if IME sets
`Selection` to current range, we should not update `Selection` with the log of
`ContentEventHandler`. Otherwise, new content will appear at different position
in the DOM tree and it may cause different style text, etc.
`IMEContentObserver` has cache of `Selection` while an editor has focus.
Therefore, for avoiding the query cost of `Selection` for each `eSetSelection`
event, `ContentEventHandler` should be used in `IMEContentObserver` instead if
an instance is available. Therefore, this patch makes `TextComposition`
delegate the handling to `IMEContentObserver` and check `Selection` range only
when `IMEContentObserver` is available. Note that `eSetSelection` is probably
used only when editable element has focus. Therefore, it must be fine to skip
selection range check in the other cases.
Differential Revision: https://phabricator.services.mozilla.com/D171179
Newer Android supports multiple refresh rate that is dynamically changed.
Actually, GeckoView will always pass the refresh rate value to vsync when
getting it first time.
So this fix changes that GeckoView gets the refresh rate when vsync is started.
Differential Revision: https://phabricator.services.mozilla.com/D168665
As part of our goal to reduce GLX usage, and our exposure to its known
threading issues, let's try to ship EGL on X11 for NVIDIA binary driver
users with version 340.108 and higher. This lowers the requirement from
470.82 and higher.
Note that this does not impact shipping WebRender support to these
users. We keep the requirement for hardware acceleration at 470.82 and
higher. Thus this should predominantly impact WebGL.
Differential Revision: https://phabricator.services.mozilla.com/D171278
What is going on here is a bad interaction between the
aspect-ratio-locking that PiP uses and CSD.
The Wayland window starts off with CSD decorations. That adds some
margin to our windows. When we un-decorate the window then eventually
GDK removes those margins, which means that we end up with a different
size, due to the aspect ratio.
PiP is special enough that is probably ok to just do this.
Differential Revision: https://phabricator.services.mozilla.com/D171075
We get sometimes two color-scheme changes on GNOME + Wayland at least,
which do unnecessary work. Avoiding that extra work is rather
straight-forward.
This is a slightly simpler approach than D171065.
Differential Revision: https://phabricator.services.mozilla.com/D171081
When we initially shipped X11 EGL on Mesa 21+, it was chosen
specifically to avoid CI issues. These appear to have mostly been
resolved with minimal annotations required to enable EGL on release.
This will allow the majority of Linux Mesa users to switch away from
GLX.
With this patch, we will match shipping X11 EGL on where we chose to
ship WebRender. Specifically that is Mesa 17+ in general, and 18.2+ for
Nouveau.
Differential Revision: https://phabricator.services.mozilla.com/D171089
Adds a usePageRuleSizeAsPaperSize setting to allow overriding the default paper size when printing to a PDF file.
Print preview now checks for at-page size rules and when enabled will use that size for the previewed sheet of paper.
The preview will also return the page width and height (in inches) during its callback for the frontend to use to override the default paper settings.
Differential Revision: https://phabricator.services.mozilla.com/D160303
Now it's on by default everywhere, so all this is not needed. No behavior
change effectively since the xul.css bits being removed effectively achieve the
same.
Differential Revision: https://phabricator.services.mozilla.com/D170944
Recently we add DMABufSurface reference when DMABufSurface is exported over IPC bridge by Serialize().
That no longer works as Serialize() may be called more times due to WebGL integration.
In this patch remove ref add in Serialize() (GlobalRefCountExport) and add global ref when it's
created/imported by IPC bridge.
That better matches DMABufSurface cycle in compositor as DMABufSurface is referenced on create and undef when it's deleted on compositor side.
Also add logging to ref/unref and print warning if surface ref count is already zero (we're trying to unref already 'unused' surface).
Differential Revision: https://phabricator.services.mozilla.com/D170624
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
Thus, this detects the presence of libX11 version 1.7 or greater, and if not
found, we disable FEATURE_THREADSAFE_GL to disable the CanvasRender thread.
Differential Revision: https://phabricator.services.mozilla.com/D170992
- We want to get window size from compositor widget as it matches window size used by parent RenderCompositorSWGL rendrer.
- For main thread rendering mCompositorWidget is not available so get window size directly from nsWindow.
Depends on D169906
Differential Revision: https://phabricator.services.mozilla.com/D169907
Convert the various capture* constants in nsIFilePicker into a proper
enum, and perform validation when passing it across IPC.
Additionally, unlike the previous two enums, reduce the size of
CaptureTarget to 8 bits. This is a workaround for its use with
nsAttrValue, which at present very specifically requires that parseable
enums' values fit within an `int16_t` -- and a `uint16_t` does not.
Differential Revision: https://phabricator.services.mozilla.com/D169854
Convert the various mode* constants in nsIFilePicker into a proper
enum, and perform validation when passing it across IPC.
Differential Revision: https://phabricator.services.mozilla.com/D169853
Convert the various result* constants in nsIFilePicker into a proper
enum, and perform validation when passing it across IPC.
Differential Revision: https://phabricator.services.mozilla.com/D169852
Other browsers don't do this, and it might confuse users, see e.g., [1]
and bug 1813684.
Before Firefox 110, we didn't do it consistently, but I fixed that in
bug 1807687. See comments in the patch for context, [2] in particular:
> The code being removed here is intended to implement the Windows
> setting 'Underline access keys' in the Keyboard Accessibility
> control panel, which somewhat confusingly also controls whether
> focus rings appear by default when clicking on controls. The former
> part -- the showing and hiding of the underlines based on the
> setting -- was never yet implemented, this is bug 25894. The focus
> rings part was implemented.
Given:
* This setting is confusing.
* Modern windows apps and other browsers don't follow it.
* We already provide other means of achieving the same behavior
(browser.display.show_focus_rings=true).
It seems better to remove. I asked Neil in bug 1813684 in case he felt
more strongly about this, and didn't hear back.
[1]: https://www.reddit.com/r/firefox/comments/116n3kp/why_is_firefox_110_now_putting_a_blue_box_around/
[2]: https://phabricator.services.mozilla.com/D165578#5448547
Differential Revision: https://phabricator.services.mozilla.com/D170395
IME for ibus may send composition after filtering `GDK_KEY_PRESS` event
asynchronously. In that case, IME or ibus usually synthesize `GDK_KEY_PRESS`
again for letting the application know what's being handled. However, according
to the bug report, IME may send composition without synthesizing the
`GDK_KEY_PRESS` event.
Without this patch, `IMContextWrapper` dispatches only
`eContentCommandInsertText` event. Then, it'll cause only a set of
`beforeinput` and `input` events. Therefore, web apps may fail to do something
if they listen only composition and keyboard events only in Gecko. For avoiding
Gecko only failure in this case, we should make `IMContentWrapper` handle the
composition with `GDK_KEY_PRESS` event in the queue which it has not handled
yet. Then, web apps can work with `keydown` events whose `key` is `"Process"`.
Differential Revision: https://phabricator.services.mozilla.com/D170031
- We want to get window size from compositor widget as it matches window size used by parent RenderCompositorSWGL rendrer.
- For main thread rendering mCompositorWidget is not available so get window size directly from nsWindow.
Depends on D169906
Differential Revision: https://phabricator.services.mozilla.com/D169907
The datetime picker uses `outline-style: auto` (no other piece of chrome
UI does yet, afaict), and it looks real bad on Linux because
outline-style: auto is broken.
It's also slow, since we don't support webrender for it.
On Windows it's a 1px black outline, which is also terrible and can be
achieved in other ways.
On macOS the outline looks nice, but it seems better to make it
consistent across platforms, which allows the front-end to use it (I
don't think there's a use for the non-native outline).
Differential Revision: https://phabricator.services.mozilla.com/D170222
This is to make GetDPIRatioForScrollbarPart thread-safe for stylo usage.
This was using the widget for bug 1727289, but just looking at the print
preview scale is enough to fix that.
Reviewed in: https://phabricator.services.mozilla.com/D168148
For that we need to:
* Make GetDPIRatioForScrollbarPart thread-safe: This was using the
widget for bug 1727289, but just looking at the print preview scale
is enough to fix that.
* Make nsPresContext::UseOverlayScrollbars() thread-safe: We store the
RDM pane stuff in the pres context.
The rest is pretty straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D168148