Onboarding on Windows has lost the Restore from Backup button which was located on the default/pin page
Categories
(Firefox :: Messaging System, defect, P1)
Tracking
()
People
(Reporter: bmaris, Assigned: mviar)
References
Details
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-release+
|
Details | Review |
Found in
- Nightly 158.0a1
Affected versions
- Nightly 158.0a1
- Firefox 157.0b2
- Firefox 156.0
Tested platforms
- Affected platforms: Windows 10, Windows 11
- Unaffected platforms: MacOS 13, Linux
Steps to reproduce
- Visit about:welcome
- Click
Don't restorebutton
Expected result
- In the past on Windows there was the with Default/Pin that had a "Restore from Backup" button which went back to the Restore page, just as the one from Mac and Ubuntu which still exists right now.
Actual result
- The Restore from Backup button is gone now since the onboarding has changed for Windows. The only way for the user to go back right now is to click the Back button from the navigation buttons. Not sure if this change was intentional or not.
Regression range
- Well this is not necessarily a regression since the onboarding has changed intentionally but I am not sure if missing the Restore from backup button missing is intentional or not.
On Windows builds where the OS-level pin prompt applies, AboutWelcomeDefaults.sys.mjs drops AW_EASY_SETUP entirely unless the user still needs set-default, because WIN_OS_PIN_PROMPT_ENABLED falsifies the doesAppNeedPin clause, and that screen holds the only restore-from-backup-secondary-top-button at #451-462. macOS and Linux keep the screen through that same clause, which is why they still show the button. The compensating CTA on AW_IMPORT_SETTINGS_EMBEDDED at #594-606 is gated on backupRestoreEnabled && isDefaultBrowser && !doesAppNeedPin, the pre-segmentation condition for easy setup being skipped, so with doesAppNeedPin still true it does not render either and no screen in the flow carries the CTA. The gate went stale when bug 2054477 (1ab252154cab) reworked the easy-setup targeting.
Fix: Factor AW_EASY_SETUP's targeting into a shared constant in MessagingTargetingConstants.sys.mjs and gate the import screen's restore CTA on backupRestoreEnabled && !<that constant>, so exactly one CTA renders whichever screen survives, then add a Windows pin-prompt plus already-default case to browser_aboutwelcome_screen_targeting.js asserting the CTA is still reachable.
Suggested severity: S3. Windows users lose the in-flow entry point back to restore-from-backup on first run, which is a data-migration affordance rather than broken functionality, and the navigation Back button still reaches the restore screen.
If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.
If you want to categorize your feedback you can add one of the following tags: ai-triage-wrong-file, ai-triage-wrong-cause, ai-triage-hallucination, ai-triage-out-of-scope, ai-triage-wrong-fix, ai-triage-shallow-fix.
Needinfo hackbot@mozilla.tld to have a patch generated for this bug, include any questions or directions as needed in your comment.
Updated•15 days ago
|
Updated•14 days ago
|
Comment 4•13 days ago
|
||
| bugherder | ||
Comment 5•13 days ago
|
||
The patch landed in nightly and beta is affected.
:mviar, please make an uplift decision for beta:
- Nominate the patch for beta uplift approval if the fix should be included in this release, or
- Set
status-firefox157towontfixif the fix can wait for the next release.
See Requesting an Uplift for documentation on how to request an uplift.
For more information, please visit BugBot documentation.
Updated•12 days ago
|
Comment 7•8 days ago
|
||
firefox-release Uplift Approval Request
- User impact if declined/Reason for urgency: New users who need to restore from backup on a new device will not see the option to do so if they qualify to see OS-level prompts for pinning and setting default (which is a majority of Windows users).
- Code covered by automated testing?: yes
- Fix verified in Nightly?: no
- Needs manual QE testing?: yes
- Steps to reproduce for manual QE testing: See STRs in the bug.
- Risk associated with taking this patch: low
- Explanation of risk level: Changes limited to about:welcome screen targeting and related tests
- String changes made/needed?: No
- Is Android affected?: no
Original Revision: https://phabricator.services.mozilla.com/D328301
Updated•6 days ago
|
Updated•6 days ago
|
| Reporter | ||
Comment 9•6 days ago
|
||
Verified that using latest Nightly 159.0a1 and Beta 158.0b1 across platforms (windows 11, macOS 26 and Fedora 44) the Restore from Backup button is back on the first page of the onboarding (Import data) and is working as intended.
Not marking the status of the bug as verified since there is a possibility to also uplift to 157 Release.
Updated•1 day ago
|
Updated•1 day ago
|
Comment 10•1 day ago
|
||
| uplift | ||
| Reporter | ||
Comment 11•19 hours ago
|
||
Also verified as fixed using Firefox 157.0.1 Release across platforms (Windows 11, macOS 13 and Ubuntu 22.04).
Description
•