For MSIX packages, the package AUMID is used.
For NSIS/MSI installs, AUMID is retrieve from HKCR.
For portable builds, the registry is updated at runtime to populate icons, display name, and the COM server.
The COM server has been registered as will be implemented using DllSurrogate; this allows us to offload managing the eventloop and lifetime of the COM server to dllhost.exe, and minimizes the added code complexity.
The COM server is loaded as a separate executable from the sending process to prevent issues that would occur when multiple instances of the sending process (e.g. profiles running in parallel) try to stand up parallel COM servers. The separated COM executable also allows for multiple applications to share a common COM server.
Bonus: fixes Bug 1500054, Bug 1766095, and Bug 1743424.
Differential Revision: https://phabricator.services.mozilla.com/D151739
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
Destroying the IAudioSessionControl has concurrency issues with audio playback that require it to be done on the main thread. We have been trying to create a new AudioSessionControl on a background thread while this happens but some AudioSessionControl internals/dependencies are not thread safe. In order to avoid concurrency crashes, we destroy the old IAudioSessionControl on the main thread, then dispatch the restart to a background (MTA) thread asynchronously.
Differential Revision: https://phabricator.services.mozilla.com/D152302
A deadlock issue with our main thread audio playback handling arises when we try to destroy the AudioSessionControl from the MTA, despite it being an MTA object. We therefore dispatch its destruction to the main thread (STA) so the deadlock is impossible. In order to use it from the STA, we should wrap it in an AgileReference.
Differential Revision: https://phabricator.services.mozilla.com/D152301
Concurrent operations in the MTA make the required lifetime of the AudioSession complex. In particular, it cannot be known when/if any methods are currently queued or being executed (in particular, Start). In order to make this safe, we keep the AudioSession at least as long as XPCOM is running background threads.
This patch also removes a long-defunct state machine and does some basic code cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D152300
These don't get styles early enough to make a shadow decision before Show().
This also matches the previous behavior (nothing would set
nsWidgetInitData::mDropShadow for these windows), so this is the less risky
fix.
It seems somewhat sketchy to use a popup window for these to begin with (Linux
for example maps them to a toplevel Window, at least on Wayland...), but let's
not change too much right now.
The hbrBackground change is a no-op because we can't have a brush before
Create() is called, we update it in SetBackgroundColor().
Differential Revision: https://phabricator.services.mozilla.com/D153095
When the user wishes to open the window with the mouse, the shell sends NIN_SELECT.
We could continue to use WM_LBUTTONUP there, but the semantic notification is probably better.
When the user presses the space/enter key to open the window, the shell sends NIN_KEYSELECT.
When the user activates the context menu either with the mouse or the keyboard (applications/shift+f10 key), the shell sends WM_CONTEXTMENU.
Differential Revision: https://phabricator.services.mozilla.com/D152234
From Bug 1774869, current events watching by WindowOcclusionCalculator is not enough. EVENT_SYSTEM_CAPTUREEND event is added like chromium.
Differential Revision: https://phabricator.services.mozilla.com/D152250
Manage their shadow style per-window instead. It is a bit unfortunate, but
alas, seems to work, and we had existing code for various workarounds, so it's
not too gross.
The menulist special-case isn't needed anymore, menulists always have
eTransparencyTransparent nowadays on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D151994
A bug is not reported related to "zero copy hardware decoded video" on Windows. Zero video frame copy needs "reuse decoder device ". And it is already enabled on Nightly / Early Beta by Bug 1773714.
RadeonBlockNoVideoCopy is renamed to RadeonBlockZeroVideoCopy
Differential Revision: https://phabricator.services.mozilla.com/D152139
1. `requireInteraction` already existed, but it doesn't do anything.
This patch makes it mean `scenario="reminder"` in the Windows
Toast notification schema: see
https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-toast.
2. `actions` is intended to eventually support the Chrome-only
extension to the Web Notifications API: see
https://developer.mozilla.org/en-US/docs/Web/API/Notification/actions.
3. We run into an `xpconnect` limit on the number of supported
parameters. Rather than bump the limit, which has global
consequence, I added a second `init*` method. The existing
abstraction is horrible, but I can't rework it within my
timelines. Should we choose to invest, we might migrate to WebIDL
so that we can sensibly use options objects.
Differential Revision: https://phabricator.services.mozilla.com/D150667
This also provides an entry point for Windows-specific styling of
alerts, should specific consumers want one: e.g.,
`nsIWindowsAlertsService.showWindowsAlert(...)` allowing to configure
the toast template, for example.
Differential Revision: https://phabricator.services.mozilla.com/D151187
1. `requireInteraction` already existed, but it doesn't do anything.
This patch makes it mean `scenario="reminder"` in the Windows
Toast notification schema: see
https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-toast.
2. `actions` is intended to eventually support the Chrome-only
extension to the Web Notifications API: see
https://developer.mozilla.org/en-US/docs/Web/API/Notification/actions.
3. We run into an `xpconnect` limit on the number of supported
parameters. Rather than bump the limit, which has global
consequence, I added a second `init*` method. The existing
abstraction is horrible, but I can't rework it within my
timelines. Should we choose to invest, we might migrate to WebIDL
so that we can sensibly use options objects.
Differential Revision: https://phabricator.services.mozilla.com/D150667
This also provides an entry point for Windows-specific styling of
alerts, should specific consumers want one: e.g.,
`nsIWindowsAlertsService.showWindowsAlert(...)` allowing to configure
the toast template, for example.
Differential Revision: https://phabricator.services.mozilla.com/D151187
`browser.privacySegmentation.enabled` is going to be set when users opt into Felt Privacy. When I originally wrote some of this code I naively used it to pref things on, on the assumption that there would never be a situation where it would be `true` before 106 (when we remove the pref-off for this work).
However, we want to run an experiment with pinning private browsing to the taskbar ahead of 106. To avoid any possibility of accidentally opting users into Felt Privacy without their consent, let's use a distinct pref for turning these features off for now. This pref will disappear in the 106 cycle, as none of this code needs to be behind one at that point - so I don't _think_ this needs to go in `firefox.js`.
Differential Revision: https://phabricator.services.mozilla.com/D151065
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Reuse decoder device also to release on intel GPU on Windows, since it is also necessary for zero copy hardware decoded video.
Reuse decoder device handling is also updated as aligned to FEATURE_HW_DECODED_VIDEO_ZERO_COPY.
Differential Revision: https://phabricator.services.mozilla.com/D150448
This basically pref-gates some of the accent-color changes that landed before
the soft-freeze to match current release behavior, at least for now.
In the future we might want to reconsider turning these on, but at the very
least we should figure out a good story for the grey-ish accent colors, see the
comments in the pref definitions.
The only tricky bit is the use-theme-accent pref handling. I made it specific
to the non-native-theme again so that AccentColor and NNT kept behaving
consistently, but AccentColor in the browser chrome used the real accent color.
Differential Revision: https://phabricator.services.mozilla.com/D150339
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Also includes the Fn key, which isn't documented to map to a special virtual key code but maps to 0xff, an undefined code, on tested machines.
Differential Revision: https://phabricator.services.mozilla.com/D149928
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
This matches UWP apps like Settings on Windows 11, and what we do for other
desktop platforms too.
The system colors match the ones from Win32 otherwise, but using UIUtils we can
access the accent color pallete from UWP apps.
Add a pref just to be safe in any case.
Differential Revision: https://phabricator.services.mozilla.com/D149905
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
The unpainted non-client region leaves a white bar at the bottom of the window when maximized on Win11 with auto-hidden taskbar. This region is where a user can mouse-over to expose the taskbar. Painting it black eliminates the row of white pixels and fixes problems with exposing the hidden taskbar. Windows 10 usually (correctly) paints a sliver of the taskbar in this region with or without this patch. However, it also has similar (but more complex) failing edge cases discussed in the bug.
Additionally, bug 758280 used 1px for the autohidden region size but the real size is 2px so we switch to that here.
Differential Revision: https://phabricator.services.mozilla.com/D148834
Since Windows 8, ABM_GETAUTOHIDEBAREX has provided a way to identify if/where the system taskbar is hidden, even in multi-monitor setups. This adds a function to easily fetch that information.
Differential Revision: https://phabricator.services.mozilla.com/D148833
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
Butkovits Atila
Nicholas Rishel
Nika Layzell
David Parks
Emilio Cobos Álvarez
Florian Queze
James Teh
Daniel Q
sotaro
Nick Alexander
Kelsey Gilbert
Ben Hearsum
Kris Maglione
Noemi Erli
criss
Marian-Vasile Laza
Gabriele Svelto
Neil Deakin
Sean Burke