1630001 - Revise user-facing "Lightning" strings in Thunderbird so they no longer say "Lightning"

Status: RESOLVED FIXED

(Calendar :: General, task)

Description

[Paul Morris [:pmorris]]

Let's not confuse users by mentioning "Lightning" now that calendar is built in to Thunderbird.

Comment 1

[Paul Morris [:pmorris]]

Attachment: Bug 1630001 - Remove unused migration.properties "Lightning" strings. r?darktrojan

Comment 2

[Paul Morris [:pmorris]]

Attachment: Bug 1630001 - Remove imip bar "Lightning" string from lightning.properties. r?darktrojan

Depends on D71126

Comment 3

[Paul Morris [:pmorris]]

Attachment: Bug 1630001 - Remove repack directory and "Lightning" strings from lightning.properties. r?darktrojan

Depends on D71127

Comment 4

[Paul Morris [:pmorris]]

Attachment: Bug 1630001 - WIP: remove "Lightning" strings from schema prompt. f?darktrojan

Depends on D71128

Comment 5

[Paul Morris [:pmorris]]

Comment on attachment 9140920 [details]
Bug 1630001 - WIP: remove "Lightning" strings from schema prompt. f?darktrojan

This patch involving schema errors is less straightforward than the others, so requesting feedback. This patch removes the "Lightning" strings and the code to disable the add-on, and changes the "restart" button to "quit" (since there's no point in trying to restart).

When I tested it by calling this.alertAndQuit from the top of createCalendar I kept getting the prompt over and over, like it either wasn't quitting at all, or was restarting instead.

Stepping back, should we handle this schema error situation differently now? Needs some thought. We don't want to lock users out of using Thunderbird over calendar data schema issues. So we may need to offer them a choice of how to handle it.

Comment 6

[Geoff Lankow (:darktrojan)]

(In reply to Paul Morris [:pmorris] from comment #5)

Stepping back, should we handle this schema error situation differently now? Needs some thought. We don't want to lock users out of using Thunderbird over calendar data schema issues. So we may need to offer them a choice of how to handle it.

Yes, I think we should. Users are already prevented from downgrading Thunderbird, and if they work around that it's on them.

That said, if we detect a higher database schema version we could do something more useful than refusing to start, like creating a backup of the file as it was and continuing. Future schema changes are likely to be either small things like adding columns to tables (which is fine in a lot of cases), or complete overhauls (which is going to stuff the downgrading user, and should've created a backup on upgrade anyway).

Comment 7

[Paul Morris [:pmorris]]

Thanks for the feedback. That makes sense to me. I think I'll spin this out into its own bug, since it's going to go beyond just string changes.

Edit: this is now bug 1630818

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7ce08d6a4dd2
Remove unused migration.properties "Lightning" strings. r=darktrojan
https://hg.mozilla.org/comm-central/rev/1f6cbbf41d09
Remove imip bar "Lightning" string from lightning.properties. r=darktrojan
https://hg.mozilla.org/comm-central/rev/5b27d2fdc334
Remove repack directory and "Lightning" strings from lightning.properties. r=darktrojan