It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
When Firefox was activated by Alt+Tabbing, there was a case that event hook of WindowOcclusionCalculator could not detect an event of window activated. Then it is necessary to trigger window occlusion calculation from nsWindows.
Differential Revision: https://phabricator.services.mozilla.com/D132206
It is helpful if window visibility state could be checked by debug overlay.
For now, it works only on Windows with compositor.
Differential Revision: https://phabricator.services.mozilla.com/D131807
The previous patch would be a better fix, but it causes some xpcshell
crashes on Linux which I haven't figured out yet (because initializing
LookAndFeel initializes gfxPlatform).
This should be less risky and still fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D132011
This patch simply avoids calling SetAppID and SetCurrentProcessExplicitAppUserModelID when we're running from a packaged app. For `SetCurrentProcessExplicitAppUserModelID`, I ended up skipping the calls to the functions that call it because I thought it was less surprising behaviour given the names (eg: I might be surprised if `SetTaskbarGroupId` silently didn't set the taskbar group id). It's easy enough to switch up if skipping the calls at a lower level makes more sense.
I couldn't find any automated tests around the Jump List functionality (and we don't have any tests running within MSIX packages yet anyways...), but it worked just fine in my manual test. I also tested the scenario where the AppxManifest.xml ID changes during an upgrade (which will probably happen when https://bugzilla.mozilla.org/show_bug.cgi?id=1736113 gets done). This causes Jump Lists to stop working at first restart, but they appear to rebuilt after the usual few minute wait.
Differential Revision: https://phabricator.services.mozilla.com/D131693
This re-arranges some deckchairs, allowing to have the launcher
process query the Windows packaged app environment.
Depends on D129882
Differential Revision: https://phabricator.services.mozilla.com/D130187
This ends up enabling hw-wr on nightly on gen6 which was left disabled
for testing sw-wr, but should otherwise have no (or at least limited)
impact.
Differential Revision: https://phabricator.services.mozilla.com/D130926
This is always available and makes it more consistent for comparing print
settings.
Also change to round when converting back to DEVMODE for better accuracy.
Depends on D99810
Differential Revision: https://phabricator.services.mozilla.com/D99811
This is to allow settings saved in prefs to be validated against a printer and
for print preview to be updated if any changes affecting layout occur.
Differential Revision: https://phabricator.services.mozilla.com/D98458
This is a expected situation specially after RemoteLookAndFeel was
enabled (which queries the whole int range).
No point in spamming the console.
Differential Revision: https://phabricator.services.mozilla.com/D130739
Previously this code was using ipc::DuplicateHandle, which was unnecessary, as
the code is being run in the parent process which has access to perform direct
handle transfers. After this patch we'd like to remove ipc::DuplicateHandle and
rely only on attached handles for serialization, so the code is converted to
instead directly use DuplicateHandle.
Differential Revision: https://phabricator.services.mozilla.com/D126571
Essentially, we just want to make sure that one of our windows has focus before
we run this handler, as it will likely want to focus a specific window. We can
focus any window we want as long as *one* of our windows has been focused
already with ::SetForegroundWindow. This patch just does that.
Additionally, per cmartin's request, I added MOZ_DIAGNOSTIC_ASSERTs before some
of the early exits here, as I don't think they should be reachable? But please
do let me know if you'd prefer to keep them out or if I'm wrong about them
being reachable.
Differential Revision: https://phabricator.services.mozilla.com/D130222
Previously this code was using ipc::DuplicateHandle, which was unnecessary, as
the code is being run in the parent process which has access to perform direct
handle transfers. After this patch we'd like to remove ipc::DuplicateHandle and
rely only on attached handles for serialization, so the code is converted to
instead directly use DuplicateHandle.
Differential Revision: https://phabricator.services.mozilla.com/D126571
Fix a mistake during porting the ComputeNativeWindowOcclusionStatus() from chromium to gecko. chromium uses (left, top right, bottom), but gecko needs to use (x, y, width, height).
Differential Revision: https://phabricator.services.mozilla.com/D130331
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
GetWindowDesktopId is a slow function and is called on the UI thread during WM_CLOSE message handing (as part of SessionStore). This was causing Windows to assume we are stalled and it abandons some messages, namely future WM_CLOSE messages sent for other windows during a "Close All Windows" operation.
In this patch, GetWorkspaceId uses a cached value for GetWindowDesktopId (if available) but also queues an update for that cache value if one isn't already in progress. Since SessionStore already regularly calls GetWorkspaceId in response to window moves, this keeps the value fresh in plases where it might change. (The SessionStore architecture is designed that way because Windows does not notify the application if the user moves the window to another virtual desktop.)
Differential Revision: https://phabricator.services.mozilla.com/D128955
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
This fix simply ignores tablet mode when running on Windows 11. The
reasoning behind this is that per Microsoft documentation tablet mode
is specific to Windows 10 and not supported anymore on Windows 11. This
seems consistent in the behavior of the APIs we use to detect the
presence of a keyboard: Windows 10-specific APIs return unexpected
results while APIs that predate them return values that seem consistent
and reliable.
Differential Revision: https://phabricator.services.mozilla.com/D128229
We want to be able to have a different behavior for interactions with an entry
in the Windows system tray - specifically, we want to be able to open a window
on left click, and show a menu on right click. This patch allows us to control
this with a "contextmenu" attribute on the menu passed in to `AddItem`, and
receive a "systemstatusbarclick" event in the case of a left click.
Regarding tests, I don't know that we have a good way of testing this?
Suggestions are of course welcome here.
Differential Revision: https://phabricator.services.mozilla.com/D129413
For Bug 1733955, we need a support of dynamic enabling/disabling window occlusion by pref. It is for enabling/disabling window occlusion for some mochitests by pref.
Differential Revision: https://phabricator.services.mozilla.com/D129369
We use "is-in-chrome-docshell" rather than "is a chrome doc" so that about:
pages that are loaded in the content area (like about:addons etc) follow the
general content theme as well.
Cache the relevant color schemes since having that many branches on the default
system theme made me a bit uncomfortable, and this code can be called quite a
lot... Though it probably isn't such a huge deal. This makes us initialize the
theme right away, so make sure subclasses do the right thing. This in practice
was only an issue for GTK, which does cache the "system theme is dark" bit.
Differential Revision: https://phabricator.services.mozilla.com/D128674
Since we don't handle WM_NCPOINTER* touch events, Windows resends them as WM_NCLBUTTON* events but leaves the special touch-indicators set in thread extra data (::GetMessageExtraInfo). This extra data causes our event to be ignored as a "touch-generated mouse event" that isn't part of an APZ drag. This patch skips that check for these specific window-button mouse events.
Differential Revision: https://phabricator.services.mozilla.com/D128771