WDBA notification is not displayed on some Windows 10 machines
Categories
(Toolkit :: Default Browser Agent, defect, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox119 | --- | affected |
People
(Reporter: vsangerean, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
287.34 KB,
image/png
|
Details |
Found in
- Nightly 119.01a (14-09-2023)
Affected versions
- Nightly 119.01a (14-09-2023)
Tested platforms
Affected platforms: Windows 10
Unaffected platforms: Windows 11
Preconditions
- Have a clean environment, with no FF installed
Steps to reproduce
- Download the Nightly installer
- Install Nightly in a custom location (EX: in the D:/test)
- Set Nightly as the default browser
- Open a CMD in the installation folder
- Drag and Drop the "default-browser-agent" file between double commas in the CMD
- Open Task Scheduler -> Mozilla and open the Default Browser Agent task
- Go to the action tab and copy the arguments
- Paste the arguments in the CMD and ad --force at the end of the command (The final command should look like this: D:\test>"D:\test\default-browser-agent.exe" do-task "AE6C84DFC9B9D0AC" --force) end press ENTER
- Set Edge as the default browser
- Rerun the command in CMD
Expected result
- The WDBA notification should pop up.
Actual result
- On some Windows 10 machines, the notification does not pop up.
Additional notes
- We attempted to find a clear reproduction path, however we could not find anything specific in registries or machine configurations.
Comment 1•1 years ago
|
||
:vsangerean, if you think that's a regression, could you try to find a regression range using for example mozregression?
Comment 2•1 years ago
|
||
Could we get a list of working and non-working custom install locations?
Updated•1 years ago
|
Reporter | ||
Comment 3•1 years ago
|
||
We tested with the same paths for all machines. On the machines in which we could not trigger the notification from custom locations, we could trigger them with default install.
The used locations are:
C:\Test
C:\Builds
D:\test
D:\New Folder
D:\Firefox Nightly
Comment 4•1 years ago
•
|
||
Could you verify the default agent works with the currently stable release of Firefox on these machines?
My first guess is an old version of Windows 10 is being tested? If so then the issue may be that we're using a notification API that isn't supported on older versions of Windows, in which case we can probably leave this unresolved for now. I just tested on a system that dates back to the non-Chrome Edge, which is quite old so I think we can rule this out.
If that doesn't narrow things down, are there any other patterns such as being a 32 bit install/machine or specific system locales?
Updated•1 years ago
|
Reporter | ||
Comment 5•1 years ago
|
||
I can only access one of the machines where the bug reproduces, for the moment.
I can confirm that the WDBA works for 117.0.1 Firefox.
The machine is a Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz with 16 GB of RAM.
OS details:
Edition Windows 10 Pro
Version 22H2
Installed on 9/17/2021
OS build 19045.3324
Experience Windows Feature Experience Pack 1000.19041.1000.0
Please let me know if any more information is required.
Comment 6•1 year ago
|
||
Could you verify notifications have not been turned off in Windows system settings for Firefox on the machine? You can do this either via checking Notifications & actions
in the Settings
, or by opening Firefox and checking if you can create a notification from e.g. https://bgrins.github.io/devtools-demos/misc/notifications.html.
Updated•1 year ago
|
Reporter | ||
Comment 7•1 year ago
|
||
Notifications are on, they work for 117.0.1 Firefox installed in custom locations and sites such as https://cleverpush.com/en/test-notifications/ and https://bgrins.github.io/devtools-demos/misc/notifications.html
Please not that the WDBA notification also works if Nightly is installed in the default location. The issue occurs only for Custom locations as exemplified above.
Comment 8•1 year ago
|
||
On the affected system, could you check the Windows Event Viewer to see if there's a relevant error under Windows Logs > Application
.
Reporter | ||
Comment 9•1 year ago
|
||
Event viewer Error provided:
Log Name: Application
Source: Firefox Nightly Default Browser Agent
Date: 9/21/2023 5:42:02 PM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SVROLP01960
Description:
The operation completed successfully.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Firefox Nightly Default Browser Agent" />
<EventID Qualifiers="0">0</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-09-21T14:42:02.8489167Z" />
<EventRecordID>129992</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>Application</Channel>
<Computer>SVROLP01960</Computer>
<Security />
</System>
<EventData>
<Data>Error: The library was not able to create a Shell Link for the app (ShowNotification:438)</Data>
</EventData>
</Event>
Comment 10•1 year ago
|
||
I'm occasionally able to recreate this, but unfortunately not reliably.
The relevant code that's failing here (AUMID mismatch/not present on start menu shortcut) is scheduled to be replaced in Fx120, so I think the appropriate remediation is to watch the Beta cycle and only take action if it's clear this is a widespread issue.
Reporter | ||
Comment 11•1 year ago
|
||
During the pre-release testing session we managed to reproduce the issue also on Windows 11 OS.
What we have found out is that this occurs on workstations which have security limitations set by the company.
I am thinking that these limitations could cause the blocking of the notification with the error message : "Error: The library was not able to create a Shell Link for the app (ShowNotification:438) "
Thank you!
Comment 12•1 year ago
|
||
Thanks for the follow up Virgil! (sorry this was lost in my email backlog).
It would be interesting to know if Windows notifications work in Firefox (not the XUL notification fallback) on these systems that are seeing an issue? If so that would increase our confidence that moving forward with the migration from WinToast to nsIAlert is the right course of action.
Reporter | ||
Comment 13•1 year ago
|
||
Hello.
I just tested on the machine with the initial issue, using both Nightly 121 and the stable release of Firefox 120 and saw that all notifications work as expected, with the exception of the WDBA notification reported in this bug.
Additionally I tested notifications from other browsers such as Chrome and Opera and saw that all notifications that were tested work as exepected.
Please tell me if there is anything else I can help with.
Thank you!
Comment 14•1 year ago
•
|
||
Thanks Virgil! I'll continue with my prior suggestion - prioritize migrating to nsIAlert
instead of attempting to debug WinToast
.
Comment 15•1 year ago
•
|
||
:Virgil assuming no surprise back outs, this should now be resolved with Bug 1867144. Could we verify it was fixed on affected machines?
Edit: maybe wait until the fix for Bug 1872297 successfully lands.
Reporter | ||
Comment 16•1 year ago
|
||
Verified fixed on all machines affected by this change on 123.0a1 Nightly.
Reporter | ||
Updated•1 year ago
|
Description
•