This also fixes an issue where we'd calculate the same App ID for normal
and private browsing windows if taskbar.grouping.useprofile was set to
true.
Differential Revision: https://phabricator.services.mozilla.com/D205721
According to the Microsoft documentation, this is the maximum length
of the string allowed for the description property of an IShellLinkW.
This also adds a test for long descriptions to ensure that they are
properly truncated.
This patch also:
- Adjusts the tests a little bit to be less race-y, particularly with the
SetAppID routine in the JumpListBuilder constructor.
- Fixes the issue where the tests weren't properly copying in the intended
strings for test titles and descriptions.
Differential Revision: https://phabricator.services.mozilla.com/D193693
According to the Microsoft documentation, this is the maximum length
of the string allowed for the description property of an IShellLinkW.
This also adds a test for long descriptions to ensure that they are
properly truncated.
This patch also:
- Adjusts the tests a little bit to be less race-y, particularly with the
SetAppID routine in the JumpListBuilder constructor.
- Fixes the issue where the tests weren't properly copying in the intended
strings for test titles and descriptions.
Differential Revision: https://phabricator.services.mozilla.com/D193693
According to the Microsoft documentation, this is the maximum length
of the string allowed for the description property of an IShellLinkW.
This also adds a test for long descriptions to ensure that they are
properly truncated.
This patch also:
- Adjusts the tests a little bit to be less race-y, particularly with the
SetAppID routine in the JumpListBuilder constructor.
- Fixes the issue where the tests weren't properly copying in the intended
strings for test titles and descriptions.
Differential Revision: https://phabricator.services.mozilla.com/D193693
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
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
Now that we always have an MTA active, we don't need to explicitly try to
start it anymore. These locations in our source were doing so, which is now
not only redundant, but fails (since `EnsureMTA`'s default constructor is now
`private`).
We also fix a spot in `JumpListBuilder` where we need a lambda to capture by
reference to fix a static analysis issue.
Differential Revision: https://phabricator.services.mozilla.com/D113563
Now that we always have an MTA active, we don't need to explicitly try to
start it anymore. These locations in our source were doing so, which is now
not only redundant, but fails (since `EnsureMTA`'s default constructor is now
`private`).
We also fix a spot in `JumpListBuilder` where we need a lambda to capture by
reference to fix a static analysis issue.
Differential Revision: https://phabricator.services.mozilla.com/D113563
Now that we always have an MTA active, we don't need to explicitly try to
start it anymore. These locations in our source were doing so, which is now
not only redundant, but fails (since `EnsureMTA`'s default constructor is now
`private`).
We also fix a spot in `JumpListBuilder` where we need a lambda to capture by
reference to fix a static analysis issue.
Differential Revision: https://phabricator.services.mozilla.com/D113563
Once we start supporting different model IDs for different windows of the same
application we need to make sure that the normal windows have a model ID and
the jump lists and recent documents are tagged with the same ID. We do this by
always having an app default model ID, when no window specific model ID is set
the app default is used.
At some point we may want to extend the jump list stuff to support using a
different model ID but that isn't needed right now.
Differential Revision: https://phabricator.services.mozilla.com/D57152
Once we start supporting different model IDs for different windows of the same
application we need to make sure that the normal windows have a model ID and
the jump lists and recent documents are tagged with the same ID. We do this by
always having an app default model ID, when no window specific model ID is set
the app default is used.
At some point we may want to extend the jump list stuff to support using a
different model ID but that isn't needed right now.
Differential Revision: https://phabricator.services.mozilla.com/D57152
Once we start supporting different model IDs for different windows of the same
application we need to make sure that the normal windows have a model ID and
the jump lists and recent documents are tagged with the same ID. We do this by
always having an app default model ID, when no window specific model ID is set
the app default is used.
At some point we may want to extend the jump list stuff to support using a
different model ID but that isn't needed right now.
Differential Revision: https://phabricator.services.mozilla.com/D57152
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
Yannis Juglaret