Re-allow entering a birthday or special date without year (avoid ux-interruption, also for migrated contacts w/o year)
Categories
(Thunderbird :: Address Book, defect, P2)
Tracking
(thunderbird_esr102+ fixed, thunderbird104 fixed)
People
(Reporter: kevin, Assigned: mkmelin)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, ux-implementation-level, ux-interruption)
Attachments
(2 files)
(deleted),
text/x-phabricator-request
|
wsmwk
:
approval-comm-beta+
wsmwk
:
approval-comm-esr102+
|
Details |
(deleted),
text/x-phabricator-request
|
wsmwk
:
approval-comm-esr102+
|
Details |
With Thunderbird Daily 20220711105425, it is not possible to save a contact with a birthday (or anniversary) that lacks a year. Pressing Save results in the year field gaining a pink border, suggesting it has failed validation, and save does not proceed.
Support for saving birthdays without years was added to the back-end in Bug 469209 and briefly supported, as noted in Bug 1727633, but was recently regressed. The pushlog https://hg.mozilla.org/comm-central/pushloghtml?fromchange=818289b8740deb3227ce8dfd30e763064af5414f&tochange=921aa12828e75d533ed016df3745b7ce91113a6a suggests it was regressed by Bug 1774696.
Updated•2 years ago
|
Comment 1•2 years ago
|
||
I agree with Kevin and Wayne that saving a birthday without a year is a frequent scenario which we should continue to support.
Also, as we used to support this in TB 91 (dates without year), requiring the year now will blow up for all contacts not having a year whenever you change anything else on them, as it will want to force you to enter a year when you're not ready for that. That's a pretty pretty bad case of ux-interruption actually, because the only way out (short of entering a wrong year which is worse) would be to delete the entire date set. That's almost S2.
When this gets fixed (no year required), please re-allow entering February 29 (currently when there's no year, it assumes current year and limits to Feb 28).
I'm also not entirely sure if pre-emptive data validation (instead of post-facto) justifies the inconvenience of reversing d-m-y inputs, entering a birthday in reverse order seems a bit weird, although of course it's perfectly correct and maybe on the increase in forms.
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
Assignee | ||
Comment 3•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/aaceb4d62948
Re-allow entering a birthday or special date without year. r=aleca
Assignee | ||
Comment 5•2 years ago
|
||
Assignee | ||
Comment 7•2 years ago
|
||
Comment on attachment 9286400 [details]
Bug 1779100 - Re-allow entering a birthday or special date without year. r=aleca
[Approval Request Comment]
Regression caused by (bug #): new ab
User impact if declined: data incompatibility, and can't add special date without a year
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): should be safe
Comment 8•2 years ago
|
||
Comment on attachment 9286400 [details]
Bug 1779100 - Re-allow entering a birthday or special date without year. r=aleca
[Triage Comment]
Approved for beta
Comment 9•2 years ago
|
||
bugherder uplift |
Thunderbird 104.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/f38f91c4ceb9
Thunderbird 104.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/08ed984f73b6
Comment 10•2 years ago
|
||
Comment on attachment 9286400 [details]
Bug 1779100 - Re-allow entering a birthday or special date without year. r=aleca
[Triage Comment]
Approved for esr102
Comment 11•2 years ago
|
||
Comment on attachment 9287163 [details]
Bug 1779100 - follow-up - adjust test expecations. r=#thunderbird-reviewers
[Triage Comment]
Approved for esr102
Comment 12•2 years ago
|
||
bugherder uplift |
Description
•