Windows has different driver version semantics than other platforms. We
shouldn't pad the driver versions the same way on Linux/OSX/Android for
our blocklist rules and instead just take the numbers as given. This
really only impacted Linux since it had numerous blocklist rules which
depending on the vendor or Mesa driver versions.
Differential Revision: https://phabricator.services.mozilla.com/D138905
Make the ScreenOrientation part of the screen struct, as it should. Stop
using HAL to propagate just screen orientation updates, use the more
general screen manager.
Instead of HAL observers, add a simple observer service notification,
and clean a bunch of the code.
This will simplify bug 1754802 a bit, and is generally simpler.
Shouldn't change behavior. I've tested the events and some common
orientation locking use cases like Youtube, and they behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D138477
Implementation of WindowOcclusionCalculator::Initialize() is borrowed from InitializeVirtualDesktopManagerTask::Run().
And implementation of WindowOcclusionCalculator::IsWindowOnCurrentVirtualDesktop() is borrowed from chromium's WindowOcclusionCalculator::IsWindowOnCurrentVirtualDesktop()
Differential Revision: https://phabricator.services.mozilla.com/D133327
Users may map reserved shortcut keys of Firefox/Thunderbird as an editing
command or a navigation command. Therefore if and only if an editable element
has focus and a reserved key combination is mapped to an editing command or
a navigation command by the system settings, we should allow to dispatch it
into the content and work it as what user expects.
With this change, keyboard only users may loose some shortcut keys to leave
from a web content which blocks keyboard focus in it. However, there may
be another reserved shortcut keys to escape from such web apps only with
keyboard because it's hard to think that all reserved shortcut keys conflict
with users' settings.
Differential Revision: https://phabricator.services.mozilla.com/D138009
Querying selection for getting writing mode may run script in the main process
if focus is in it. For avoiding new users of writing mode at selection **only**
when the value is required during an editable content has focus,
`TextEventDispatcher` should always store writing mode at receiving focus
notification.
Differential Revision: https://phabricator.services.mozilla.com/D138008
I'd like to use it in `IMEData.h`. However, adding new include into it may
cause bustage with MinGW, and it's included by `nsIWidget.h` because `nsIWidget`
requires some classes defined in `IMEData.h`. Therefore, I'd like to make a
new header file for avoiding the include hell.
Differential Revision: https://phabricator.services.mozilla.com/D138007
We might want to do this on Windows 11 as well, but Windows 11 has a
system-wide preference with UI so let's not do that just yet at least,
UI-exposed preference.
Differential Revision: https://phabricator.services.mozilla.com/D138502
Perform some cleanup to bring the code in this function closer to modern
standards. (This includes, but is not limited to, the simple
variable-name change requested by the Bugzilla bug.)
This commit should have no effective functional changes.
Tested via `browser/base/content/test/general/browser_clipboard.js`,
which was confirmed to complain if changes were made to this function's
output (and, specifically, to the values in the start- and
end-positions).
Differential Revision: https://phabricator.services.mozilla.com/D138087
nsClipboard::HasDataMatchingFlavors() calls nsRetrievalContext::GetTargets() which obtains clipboard targets. We need to call Gtk code for that and spin evetn loop to get the targets.
In this patch we store clipboard tragets internally to speed up nsClipboard::HasDataMatchingFlavors() calls. We also listen at owner-change signal to clear target cache when clipboard content changes.
Differential Revision: https://phabricator.services.mozilla.com/D137899
In bug 1750569 we attempted to ensure that following a GPU process
crash outstanding screen pixels requests would be fulfilled. While
this usually worked there was a race condition between sending the
request to the new compositor and the content process sending the
display list to the new compositor, which meant that sometimes we
would screenshot an empty screen instead of the page content.
As a GPU process crash is an extraordinary circumstance and
screenshots are non-critical, the best solution is to simply return an
error if a GPU process crash occurs while there is an outstanding
request (or if a new request is made whilst the GPU process is
restarting). This patch also updates the junit test to check for this
error rather than expecting a screenshot to be returned.
Differential Revision: https://phabricator.services.mozilla.com/D138323
This is a mechanical change which was performed by a script based on the
contents of direct_call.py, and then manually checked over to fix
various rewriting bugs caused by my glorified sed script. See the
previous part for more context on the change.
Differential Revision: https://phabricator.services.mozilla.com/D137227
This is faster and more straight-forward code than the old
ShouldUseDarkScrollbar shenanigans, and allows to have dark-themed
scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D138077
Actually, we require that the parameter of promise by `GeckoResult` has copy
constructor. We should allow non-copy C++ class for this parameter.
Differential Revision: https://phabricator.services.mozilla.com/D137974
Build errors being fixed here:
layout/xul/nsDeckFrame.cpp:164:43: error: unknown type name 'nsSetAttrRunnable'
layout/xul/nsMenuBarListener.cpp:45:7: error: cannot initialize a member subobject of type 'mozilla::dom::EventTarget *' with an rvalue of type 'nsINode::Document *' (aka 'mozilla::dom::Document *')
(...where "Document" is not defined; this patch includes the header that defines it, which fixes this.)
layout/xul/nsBoxFrame.cpp:270:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
dist/include/nsIRollupListener.h:36:38: error: no type named 'LayoutDeviceIntPoint' in namespace 'mozilla'
(For this error, this patch is changing a header outside of layout/xul, but
it's still required in order for layout/xul to build properly, since it's
#included by layout/xul/nsXULPopupManager.cpp (indirectly, via its .h file).
Differential Revision: https://phabricator.services.mozilla.com/D138092
Bug 1742985 added the test helper_zoom_after_gpu_process_restart.html,
but it doesn't actually get run on any platform with the GPU process
enabled. (Due to bug 1495580 on windows, and because the GPU process
isn't yet enabled on android.)
The test kills the GPU process, then tries to wait for it to be
restarted before proceeding. However, the function
ensureGPUProcessReadyForTests doesn't always work as intended, as the
GPUProcessManager may not have yet noticed that the process has been
killed, and therefore may return immediately from EnsureGPUReady.
This patch removes the buggy ensureGPUProcessReadyForTests function,
and instead makes the test wait for the "compositor-reinitialized"
topic to be observed.
Differential Revision: https://phabricator.services.mozilla.com/D138125
Build errors being fixed here:
layout/xul/nsDeckFrame.cpp:164:43: error: unknown type name 'nsSetAttrRunnable'
layout/xul/nsMenuBarListener.cpp:45:7: error: cannot initialize a member subobject of type 'mozilla::dom::EventTarget *' with an rvalue of type 'nsINode::Document *' (aka 'mozilla::dom::Document *')
(...where "Document" is not defined; this patch includes the header that defines it, which fixes this.)
dist/include/nsIRollupListener.h:36:38: error: no type named 'LayoutDeviceIntPoint' in namespace 'mozilla'
(For this error, this patch is changing a header outside of layout/xul, but
it's still required in order for layout/xul to build properly, since it's
#included by layout/xul/nsXULPopupManager.cpp (indirectly, via its .h file).
Differential Revision: https://phabricator.services.mozilla.com/D138092
Currently, it sets "input-purpose" and "input-hints" and notify IME of focus
at updating `InputContext`. This occurs before receiving `NOTIFY_IME_OF_FOCUS`.
Therefore, at the moment, `IMContextWrapper` cannot access content cache, but
IME may query it. E.g., IME may start composition immediately
(ibus-pinyin 1.5.0-6 does it).
For avoiding the trouble, `IMContextWrapper` should notify IME of focus when
and only when it receives `NOTIFY_IME_OF_FOCUS`.
Differential Revision: https://phabricator.services.mozilla.com/D137610
Oddly, in some complicated web apps, `IMEContentObserver` may get selection
change notifications **after** sending a text change notification to IME.
However, I cannot reproduce it with simple testcase. Therefore, the new test
does not test the original issue, but the approach of this patch must avoid
regressions of this special case handling.
Differential Revision: https://phabricator.services.mozilla.com/D137522
Implementation of WindowOcclusionCalculator::Initialize() is borrowed from InitializeVirtualDesktopManagerTask::Run().
And implementation of WindowOcclusionCalculator::IsWindowOnCurrentVirtualDesktop() is borrowed from chromium's WindowOcclusionCalculator::IsWindowOnCurrentVirtualDesktop()
Differential Revision: https://phabricator.services.mozilla.com/D133327
Finally, making `WidgetQueryContentEvent::Succeeded` return `true` when there
is no selection when its message is `eQuerySelectedText`, and making
`ContentEventHandler::OnQuerySelectedText` set the no selection range data even
when the queried selection type is "normal. Then, all things which are
changed by the previous patches start to work.
And this patch adds a simple test for `ContentCache` and update tests of
`nsITextInputProcessor`.
Differential Revision: https://phabricator.services.mozilla.com/D137432
Currently, `mSelection` is cached only when `mText` is some, text rects are
cached only when `mSelection` is cached. However, as far as widget can work
with IME, it should cache content as far as possible. Therefore, this patch
makes it keep querying content data even after something fails.
Differential Revision: https://phabricator.services.mozilla.com/D137431
Even after applying this patch, it still returns error when queried with a
relative offset from selection and only when there is no composition string.
However, this shouldn't cause any problem because in this case, widget should
not try to query content with relative offset.
Differential Revision: https://phabricator.services.mozilla.com/D137430