It is not clear whether this is the cause of the crash, but it seems
plausible as it is both recent code and it clearly doesn't validate the
length of the stack-allocated buffer, so a bad gconf could plausibly
cause this.
Clean stuff up a bit and validate the buffer length.
Differential Revision: https://phabricator.services.mozilla.com/D78405
When DWM is disabled, each window does not have own back buffer. They would paint directly to a buffer that was to be displayed by the video card. WM_PAINT via SendInvalidRegion() requests necessary re-paint. With it, RenderCompositorANGLE does not need to disable partial present.
Differential Revision: https://phabricator.services.mozilla.com/D77989
On other platforms we get a mousedown event when the non-client area is clicked,
but not on Windows, where handling the WM_NCLBUTTONDOWN message breaks dragging
the window. This dispatches the mousedown event like other platforms, but on
the next tick.
Differential Revision: https://phabricator.services.mozilla.com/D77419
The probes collect counts for:
- print preview open, and exit without print
- print dialog opened from print preview, and cancelled
- print dialog opened without print preview, and cancelled
- silent prints
- print target
- PDF file
- XPS file
- other (probably print to physical printer, but we can never be sure)
There is some overlap with the existing PRINT_* probes, but I think we should
keep those in place temporarily until we confirm that the new probes produce
numbers that are consistent with the old probes.
This patch only adds 'print target' probes for Windows and macOS.
I use nsDeviceContextSpec*::Init() to collect the 'print target' telemetry
because the way we initialize settings from prefs (and the way macOS works in
particular) make it difficult to reliably determine the target type earlier in
the print process for all possible entry points into the printing code.
Differential Revision: https://phabricator.services.mozilla.com/D78033
This can be reproduced trivially on a MacBook on the test page with
layout.css.devPixelsPerPx = 1.
I wanted to fix this independently of following the outline radius.
Differential Revision: https://phabricator.services.mozilla.com/D77943
- moz_container_wayland_get_surface() is replaced by moz_container_wayland_surface_lock()/moz_container_wayland_surface_unlock()
pair which ensures the surface is locked and won't be destroyed by other thread when window is hidden for instance.
- nsWindow::GetWaylandSurface() is removed and nsWindow::GetMozContainer() needs to be used instead.
Differential Revision: https://phabricator.services.mozilla.com/D77698
Most IMEs handle arrow key, then set caret position by IME. But GBoard doesn't
handle it. GBoard will dispatch key event to application for arrow left/right
even if having IME composition.
Since Gecko doesn't dispatch key press during IME composition due to DOM UI
events spec, we have to emulate arrow key's behaviour.
And, `GeckoEditable` has a hack that composition text is committed when
dispatching key event. This hack is unnecessary after landing
bug 1613804 that `InputConnection.finishComposingText` is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D76658
When calling `InputConnection.finishComposingText` commits composition string,
but caret position isn't changed. But
`RemoveComposition(COMMIT_IME_COMPOSITION)` sets caret position to end of
string.
So we have to restore caret position after calling
`RemoveComposition(COMMIT_IME_COMPOSITION)` via `finishComposingText`.
Differential Revision: https://phabricator.services.mozilla.com/D76657
Also update documentation to suggest using the `GeneratedFile` template rather than directly referencing `GENERATED_FILES` where possible.
Differential Revision: https://phabricator.services.mozilla.com/D77496
Most IMEs handle arrow key, then set caret position by IME. But GBoard doesn't
handle it. GBoard will dispatch key event to application for arrow left/right
even if having IME composition.
Since Gecko doesn't dispatch key press during IME composition due to DOM UI
events spec, we have to emulate arrow key's behaviour.
And, `GeckoEditable` has a hack that composition text is committed when
dispatching key event. This hack is unnecessary after landing
bug 1613804 that `InputConnection.finishComposingText` is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D76658
When calling `InputConnection.finishComposingText` commits composition string,
but caret position isn't changed. But
`RemoveComposition(COMMIT_IME_COMPOSITION)` sets caret position to end of
string.
So we have to restore caret position after calling
`RemoveComposition(COMMIT_IME_COMPOSITION)` via `finishComposingText`.
Differential Revision: https://phabricator.services.mozilla.com/D76657
If key down event handler calls `event.preventDefault()`, web browser
shouldn't fire key press event. But GeckoView may fire key press
unfortunately if using software keyboard.
So we don't fire key press event when dispatching `eKeyDown` returns
`nsEventStatus_eConsumeNoDefault`.
Differential Revision: https://phabricator.services.mozilla.com/D75981
FEATURE_FAILURE_D3D11_NEED_HWCOMP is one of the main reasons
people get the basic compositor. This will let us dig into
why we get FEATURE_FAILURE_D3D11_NEED_HWCOMP.
Differential Revision: https://phabricator.services.mozilla.com/D77554
This patch implements:
- Global surface UID for better tracking/debugging. The UID is passes acros all processes so we can track
surface usage.
- WaylandAllocateShmMemory() function which uses shm_open() instead of files at tmp for Shm memory creation.
- DMABufRefcount() class based on eventfd() which is used as a global surface reference count.
Differential Revision: https://phabricator.services.mozilla.com/D76689
- Implement the nsPrinterEnumeratorX
- Enable the contract @mozilla.org/gfx/printerenumerator;1 for macOS
- Add test for default printer name.
- Remove restrictions preventing some tests from running on macOS
Differential Revision: https://phabricator.services.mozilla.com/D76356
Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.
This also addresses bug 1589893 where, when "Assign To" space is used, popup
menus are not visible in full screen mode.
With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.
Differential Revision: https://phabricator.services.mozilla.com/D75419
Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.
This also addresses bug 1589893 where, when "Assign To" space is used, popup
menus are not visible in full screen mode.
With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.
Differential Revision: https://phabricator.services.mozilla.com/D75419