The Firefox browser is re-pinned to the taskbar by the experiment after a browser update
Categories
(Firefox :: Installer, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| relnote-firefox | --- | - |
| firefox-esr68 | --- | unaffected |
| firefox70 | --- | wontfix |
| firefox71 | --- | wontfix |
| firefox72 | --- | verified |
People
(Reporter: cmuntean, Assigned: molly)
References
Details
(Keywords: regression)
Attachments
(3 files)
[Affected Versions]:
- Beta 70.0bx
- Beta 71.0bx
[Affected Platforms]
- Windows 10 x64
[Prerequisites]:
- In order to reproduce the issue, there are a few setups that need to be done. Here is a doc that describes the setups and the data used in order to reproduce the issue: Gdoc.
- Have a Firefox Beta 69.0b19 installed.
- Have an update server set and running as described in the Gdoc.
[Steps to reproduce]:
- In the directory where the Firefox Beta 69.0b16 is installed create the "distribution" folder and add the "policies.json" file described in the Gdoc from prerequisites.
- The "policies.json" file points to the local XML file that enables the browser to be updated to the 70.0b14 version.
- Open the browser and update it.
- The browser will be updated to Firefox 70.0b14 version. It will be recognized as the latest version.
- Navigate to "about:config" and add the "installer.taskbarpin.win10.enabled" boolean pref to true.
- Restart the Firefox browser.
- Right click on the Firefox browser from the taskbar and select the "Unpin from taskbar" option.
- Delete the "distribution" folder created in step 1.
- This will allow the Firefox Beta 70.0b14 to be updated to the latest version 71.0b5.
- Restart the browser and update it to the latest version (71.0b5).
- Restart the browser and observe the Firefox shortcut from the taskbar.
[Expected results]:
- The Firefox browser is not pinned to the taskbar.
[Actual results]:
- The Firefox browser is pinned to the taskbar.
[Notes]:
- Here is a link with the screen recording of the issue: Link.
|
Assignee | |
Comment 1•5 years ago
|
||
It sounds like you're saying the problem is that, if you've previously had and then removed a taskbar pin when the experimental code runs, it doesn't detect that you've removed a pin and creates one anyway? Do I understand correctly? If so, that's a known limitation and we can't really do anything about it. We don't have a way to differentiate between "the user used to have a taskbar pin here and removed it" versus "there was never a taskbar pin", because both of those states leave no trace behind; we have no way to tell that the user expressed any preference one way or the other.
When the experimental code runs, we make a record that it has run inside the installation directory, so we shouldn't try to create the pin again if it's been removed after that point.
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Molly Howell (she/her) [:mhowell] from comment #1)
It sounds like you're saying the problem is that, if you've previously had and then removed a taskbar pin when the experimental code runs, it doesn't detect that you've removed a pin and creates one anyway? Do I understand correctly?
Yes, this is the problem that I have described.
But, there are two easily encounter scenarios when you can observe this behaviour:
- The Firefox browser was never pinned to the taskbar and you are enrolled in the treatment branch of the experiment:
- The experiment will pin the browser but if you unpin it, after another browser update, the experiment will pin the browser to the taskbar again.
- The browser is pinned to the taskbar and you are enrolled in the treatment branch of the experiment:
- The browser will remain pinned but if you unpin it, after another update the experiment will pin the browser to the taskbar again.
Basically, while the user has the "installer.taskbarpin.win10.enabled" pref set to true, a Firefox shortcut will be pinned to the taskbar even if the user unpins it before each update happens.
|
|
Assignee | |
Comment 3•5 years ago
|
||
Thanks for the clarification. A second update creating the pin again after you've removed it should not be happening, there is code that's supposed to be preventing that. I will investigate.
|
|
Assignee | |
Comment 4•5 years ago
|
||
I don't understand why the problem is happening, but I see what's happening and I know how to work around it.
The method the experimental code uses to prevent creating the pin a second time is to record that it's done so already in a file inside the installation directory called the shortcut log. This is where the installer records that it tried to create a taskbar pin in the first place, so the location seemed natural, and this worked fine in the limited testing I did. The problem is that, when run by a copy of the updater that was started from the maintenance service, the helper binary isn't able to get write permission on the shortcut log. I have no idea why not; it should have been started by the updater asInvoker and the updater should have been SYSTEM, and Process Explorer clearly shows that it can write to HKLM, so that's pretty good evidence that it is running elevated. But writing to something in Program Files isn't possible for whatever reason.
I don't feel like I have time to investigate further, so I intend to work around this by moving the taskbar pin record to somewhere in the registry instead (I'm undecided about where yet).
|
|
Assignee | |
Comment 5•5 years ago
|
||
My initial idea of using the shortcuts log to store this information didn't
work out because the helper, when run by an updater which was run by the
maintenance service, doesn't get write permissions on that file.
|
||
Comment 6•5 years ago
|
||
That's mysterious, does this mean we're not able to set Migrated anymore in the log on PostUpdate, as well? I'll check, and if so I'll try to get a regression range.
|
|
Assignee | |
Comment 7•5 years ago
|
||
I didn't check; it'd be tough to tell because there aren't a lot of scenarios where we would need to set it there, as opposed to the installer having already written it, because the installer has been doing that for a long time.
Pushed by mhowell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2556a28ab75a Use the registry to record creating a taskbar pin. r=agashlin
|
|
Assignee | |
Comment 9•5 years ago
|
||
That patch didn't actually fix the problem, I'm going to add a followup.
|
|
Assignee | |
Comment 10•5 years ago
|
||
The previous patch didn't work because the helper running as the unelevated
user is the only one that can read the pref out of its user registry hive,
which is where Firefox has to write it, but then since it's limited it can't
write to either the shortcut log or to HKLM. So everything has to happen in
HKCU so that the unelevated helper can both read and write where it needs to
read and write to.
|
||
Comment 11•5 years ago
|
||
Pushed by mhowell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a16c535b92e6 Followup - Write the pinned to taskbar flag in a place the unelevated helper can write to. r=agashlin
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 12•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/2556a28ab75a
https://hg.mozilla.org/mozilla-central/rev/a16c535b92e6
|
||
Comment 13•5 years ago
|
||
Can this be uplifted to 71 to allow us running https://experimenter.services.mozilla.com/experiments/validate-retentionengagement-impact-of-pinning-a-taskbar-shortcut-for-existing-win10-users/ ?
|
|
Reporter | |
Comment 14•5 years ago
|
||
I have verified this issue on Windows 10 1809 version, but it's still reproducible. In order to verify if the issue is fixed I have followed the next steps:
- Install Nightly 67.0a1.
- The Nightly is installed and it's not pinned to taskbar.
- Using an update server I have updated the Nightly browser to 71.0a1.
- This is the build that contains the pin code for existing users.
- Add the "installer.taskbarpin.win10.enabled" boolean pref to "true".
- Using the update server I have updated the Nightly browser to 72.0a1 build from 2019-16-11.
- This is the build with the fix for this issue.
- The browser is automatically pinned to the taskbar.
- I have unpinned the Nightly browser from the taskbar.
- I have updated the Nightly browser to the latest 72.0a1 build from 2019-18-11.
- Observe the taskbar.
The Nightly browser is pinned again to the taskbar even if it was previously unpinned (in the build from 2019-16-11).
However, I have unpinned again the browser and I will update it tomorrow when the next build is available, to see if it will be pinned again.
@Molly, are these steps valid in order to verify this issue?
|
|
Assignee | |
Comment 15•5 years ago
|
||
Yeah, it's still broken. The problem this time is that I put the new registry value in a place where Firefox deletes it during the first startup after the update because it thinks it's another pref that it doesn't recognize, because I forgot that I wrote code that does that. So I need to change the registry path again.
|
|
Assignee | |
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 16•5 years ago
|
||
The previous patch writes the registry value correctly, but the Firefox
InstallerPrefs module deletes it during startup because it's in the
same key where the actual pref values go and the module unconditionally
deletes every value there. So making it only delete values that are
recognizably actual prefs should fix this.
|
|
||
Comment 17•5 years ago
|
||
I tested this out a bit with a local build and confirmed that the latest patch prevents the WasPinnedToTaskbar value from being removed. I also checked that if the reflected pref is present, and WasPinnedToTaskbar wasn't there, it gets added (and the pin is attempted, successfully on 1809).
|
|
||
Comment 18•5 years ago
|
||
Pushed by mhowell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0c4acee853c4 Followup 2 - Only clean installer pref registry values that are pref names. r=agashlin
|
||
Comment 19•5 years ago
|
||
| bugherder | ||
|
|
||
Comment 20•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
|
||
Comment 21•5 years ago
|
||
Too late for 71 given that we're out of betas.
|
|
Reporter | |
Comment 22•4 years ago
|
||
I have verified this issue and is no longer reproducible on the latest Nightly 72 builds. The Nightly browser is no longer pinned to the taskbar after an update if it was previously unpinned.
I have tested this on Windows 10 x64 1809 and Windows 10 x32 1803. I have also performed testing on Windows 10 x64 1903 to make sure that there are no regressions.
|
||
Comment 23•4 years ago
|
||
This was nominated for inclusion in release notes.
Release Note Request (optional, but appreciated)
[Why is this notable]: visible change in windows taskbar
[Affects Firefox for Android]: no
[Suggested wording]: Win10 users pre 1903 (windows_build_number < 18362) will see a Firefox shortcut placed on their taskbar. The shortcut can be unpinned and won't be pinned again.
[Links (documentation, blog post, etc)]:
Description
•