Closed Bug 1560485 Opened 1 year ago Closed 1 year ago

Remove use of DOM storage in TB account provisioner


(Thunderbird :: General, task)

Not set


(Not tracked)

Thunderbird 69.0


(Reporter: jorgk-bmo, Assigned: jorgk-bmo)




(1 file, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #1557233 +++
+++ This bug was initially created as a clone of Bug #1557018 +++

DOM storage doesn't work well in TB, in bug 1557233 I had to set a pref to get it working again. It's constantly breaking and a maintenance nightmare, see bug 1389673, bug 1515992 and bug 1551533. It's a giant hack and overkill to store a single string against a fake URL "https://accountprovisioner.thunderbird.invalid".

This patch uses a pref instead of DOM storage to store the entered user name in chase the user launches the panel again.

Attachment #9073160 - Flags: review?(ben.bucksch)

It doesn't work atm (apparently), but that's the point, we should make sure it does.

Can you please give me one good reason for using DOM storage here.

Why jump through hoops with this code
creating fake URLs, principals, running through a heap of DOM security checks and now a disabled client ID check (no idea what that is)
for the sole purpose to move one string from one panel to the other at an absolutely GIGANTIC maintenance cost. Because we can?

I don't get it. The way forward is to reduce reliance on specialised Gecko features and remove their misuse.

Flags: needinfo?(mkmelin+mozilla)
Comment on attachment 9073160 [details] [diff] [review]

Good approach.

Please change "username" to "realname", because I think the field stores the user real world name (please double-check, because I can't be certain from the patch context), not the technical username. The term "username" is a fixed term referring to an technical account name, not the real world name. Please change the pref to "mail.provider.realname".

r+ with that change done.
Attachment #9073160 - Flags: review?(ben.bucksch)
Attachment #9073160 - Flags: review-
Attachment #9073160 - Flags: feedback+

(Fixing title, because "account creation dialog" and "account provisioner dialog" are 2 completely different dialogs.)

Summary: Remove use of DOM storage in TB account creation → Remove use of DOM storage in TB account provisioner

I concur that we shouldn't be using DOM storage here. The pref should work fine.

Renamed the pref. Also restored the saveName() function to reduce code duplication and code churn. Tests pass.

EDIT: Also removed the DOM storage pref.

Assignee: nobody → jorgk
Attachment #9073160 - Attachment is obsolete: true
Attachment #9073181 - Flags: review?(ben.bucksch)
Comment on attachment 9073181 [details] [diff] [review]
1560485-dont-use-DOM-storge.patch (v2)

Good change. Thank you.
Attachment #9073181 - Flags: review?(ben.bucksch) → review+

EDIT: Also removed the DOM storage pref.

I'm presuming you made sure that the tests pass and the problems from bug 1557233 do not re-appear. I trust you on that.

See comment #6: "Tests pass" ;-)

Pushed by
Use a pref instead of DOM storage for name typed into the new account provisioner. r=BenB

Closed: 1 year ago
Keywords: checkin-needed
Resolution: --- → FIXED
Flags: needinfo?(mkmelin+mozilla)
Target Milestone: --- → Thunderbird 69.0

BTW, that stuff was implemented here:

The review comment in bug 686347 comment #6 said:
"I wonder if there's a better place to store these things than localstorage, like, say, prefs?"

The answer was:
"As I said above, no. I'm not sure the prefs are fit for storing big chunks of data like this, but we could indeed turn this into a JSON blob that's stored in the prefs."

Well, back in the days, they actually stored three strings, real name, username and domain:

Somehow two got removed since. I don't think three strings are a "big chunk of data", but we notice that concern was raised before and ignored.

domstorage is not some internal feature, but very much a web feature. That we don't run from a web page makes it not work of course... :/ I still do think a pref is the wrong place to store this temporary data, though arguably it's not important to store it at all.

In the future, please wait for feedback and don't land stuff hours after you requested it, without the feedback arriving.

Type: defect → task
You need to log in before you can comment on or make changes to this bug.