Unlike the original FaviconHelper::ObtainCachedIconFile, this new method does
all of its IO on the IO thread.
This also makes it so that the nsIJumpListBuilder exposes access to this
utility method over XPCOM.
Differential Revision: https://phabricator.services.mozilla.com/D203761
Unlike the original FaviconHelper::ObtainCachedIconFile, this new method does
all of its IO on the IO thread.
This also makes it so that the nsIJumpListBuilder exposes access to this
utility method over XPCOM.
Differential Revision: https://phabricator.services.mozilla.com/D203761
This makes sure that the transparent area is cleared properly.
We move the clear to a point where Gecko has already informed us of
the opaque region for simplicity.
Differential Revision: https://phabricator.services.mozilla.com/D207302
Trying to see whether the system-reported mouse is a REAL mouse causes problem in certain situation with Wacom driver. The driver makes the system believe it has a pen while it still reports that the input device count is 1. Our heuristic thus thinks that the single device is not a real mouse but something else, which then breaks web compatibility with Twitter.
That hack was added by bug 1493128, but the capability report behavior change is already reverted with bug 1813979. Keeping this hack thus has no point as of now. This patch follows the comment: "We shouldn't assume we know better."
Differential Revision: https://phabricator.services.mozilla.com/D197813
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Convert `nsFilePicker` to use the `Command` structs introduced in the
first commit in this patchset. No functional changes -- this should be a
straight reorganization of internal code.
Additionally, remove from `WinUtils` the now-unused function
`GetShellItemPath`, whose functionality has been moved into `Command`'s
associated functions' translation unit. (This function was added to
WinUtils in 2012 as part of supporting the Windows Vista file picker
(bug 718374). It's not overtly filepicker-specific, but in the past
eleven years, no other code has ever used it.)
Differential Revision: https://phabricator.services.mozilla.com/D178204
This patch backs out bug 1763978 for breaking resource:// loading on
Windows in certain circumstances. It isn't clear why this is happening
since all of the log evidence is showing that the paths are resolving
correctly, but we have verified that without the patch, the builds work
as expected.
We can reland the prior patch with updates once we understand the
problem. The prior patch was not critical so there is no urgency to
reuplift a fix.
Differential Revision: https://phabricator.services.mozilla.com/D177926
Rather than having `nsWindow::GetNativeData()` sometimes (argument-
dependently) create a new resource and requiring its various callers to
destroy that resource, consolidate its creation and destruction into a
single external class.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D177567
Some third party driver can create mount points without using the
Mount Manager. Without that, GetFinalPathNameByHandleW calls with
VOLUME_NAME_DOS cannot succeed. Instead we need to call it with
VOLUME_NAME_NT and convert the NT path to a DOS path using
QueryDosDevice to perform the mapping.
Prior to this patch, we would fail to load GMP plugins from
profiles mounted in a ramdisk, and potentially other situations.
See documentation for GetFinalPathNameByHandleW for more details:
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlew
Differential Revision: https://phabricator.services.mozilla.com/D174887
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
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
Now hal uses AR_STATE for screen orientation, so we should move it from
WinUtils.cpp to WinUtils.h for newer Windows 11 SDK.
Also, newer Windows SDK has to set WINVER to WIN8 to use auto rotation API.
Differential Revision: https://phabricator.services.mozilla.com/D163099
Since Windows tablet mode has a orientation lock API, this patch
implements orientation lock backend for Windows tablet mode.
`GetAutoRotationState` API recognizes whether orientation API is supported on
the device. So this fix uses this API to check orientation API capability.
Differential Revision: https://phabricator.services.mozilla.com/D162451
It was needed before we had remote lookandfeel and non-native theme, but now we
no longer call any of the APIs in child processes.
Differential Revision: https://phabricator.services.mozilla.com/D149907
Emilio Cobos Álvarez