Closed Bug 1776706 Opened 5 months ago Closed 3 months ago

Chat account input validation is too strict - requires http URL but any URI should be allowed

Categories

(Thunderbird :: Address Book, defect, P3)

Thunderbird 102

Tracking

(thunderbird_esr102+ fixed, thunderbird105 wontfix)

RESOLVED FIXED
106 Branch
Tracking Status
thunderbird_esr102 + fixed
thunderbird105 --- wontfix

People

(Reporter: u695164, Assigned: mkmelin)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

The current implementation for chat accounts (IMPP) is an input field with the type URL.

This validation is too strict and is confusing. See Thunderbird Developers Matrix chat

The vCard spec demands an URI. See IMPP.

I'm unsure how to move forward from here but my ideas are:

  • Using an input field with type text (to support legacy chat protocols)
  • Providing a suggestion list (datalist) for popular chat protocols
    • matrix:u/
    • irc:
    • xmpp:
Severity: -- → N/A
Priority: -- → P3
Blocks: tb102found
Summary: Chat account input validation is too strict → Chat account input validation is too strict - requires http URL but any URI should be allowed
Severity: N/A → S3

(In reply to Nicolai Kasper from comment #0)

This validation is too strict and is confusing.

  • Using an input field with type text (to support legacy chat protocols)
  • Providing a suggestion list (datalist) for popular chat protocols

Seconded. I think Nicolai's proposal would provide a better UX here.

FTR, Jason's testimony from Matrix:

It took some serious banging my head against a wall to figure out Tbird wants a URL here, and then more sleuthing to figure out how to turn my Matrix username into a URL. Just wanted to point out that from my POV it's not a good experience.

Add title and rolling placeholder displaying example from various protocols.

Adds displaying chat accounts on the display page - they were missing before.

Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Target Milestone: 102 Branch → 106 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/0a5f39b827d5
Clarify IMPP entry. r=aleca,freaktechnik

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED

Argh, will land a fix shortly.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/341371a444fa
follow-up to fix test and adjust impp select logic. rs=me

Reopening to fix irc protocol pattern and a selection issue Martin noticed.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/646e5a688f97
Correct irc: protocol pattern and fix protocol selection. r=freaktechnik

Status: REOPENED → RESOLVED
Closed: 3 months ago3 months ago
Resolution: --- → FIXED

Comment on attachment 9291092 [details]
Bug 1776706 - Clarify IMPP entry. r=aleca,freaktechnik

[Approval Request Comment]
Regression caused by (bug #): new ab
User impact if declined: basically broken functionality. Needed for uplifts (bug 1789990 and others)
Testing completed (on c-c, etc.): c-c beta
Risk to taking this patch (and alternatives if risky): fairly safe. has new strings but we can't do anything about that

Attachment #9291092 - Flags: approval-comm-esr102?

Comment on attachment 9291092 [details]
Bug 1776706 - Clarify IMPP entry. r=aleca,freaktechnik

[Triage Comment]
Approving despite string status. The justification is that Bug 1789990 is serious enough that it needs to be fixed now, and it required the changes in this bug that were not possible without the string changes. It's noted for the record that untranslated strings in a release version make for a poor user experience. The consensus is that having a broken feature with perceived data loss is a worse experience.
As of yesterday, 6/10 tier one locales had translated the new strings with about 33% of locales overall.

Attachment #9291092 - Flags: approval-comm-esr102? → approval-comm-esr102+
You need to log in before you can comment on or make changes to this bug.