450364 - [Win32] Installer should remove Thunderbird 3 files during downgrade to avoid potential crashes

Status: RESOLVED WONTFIX

(Thunderbird :: Installer, defect)

Description

[Robert Strong (they/them - no direct email)]

Spinoff of bug 423226 for Thunderbird. All files that exist in a Thunderbird 3 install that don't exist in a Thunderbird 2 install should be added to removed-files.in

Comment 1

[Robert Strong (they/them - no direct email)]

Serge, you probably want this for SeaMonkey too.

Comment 2

[Serge Gautherie (:sgautherie)]

Thanks, I filed bug 450504 ;-)

Comment 3

[Phil Ringnalda (:philor)]

Attachment: Untested patch

Not sure what to do with this. This is a list from following the steps in bug 423226 (install Tb 2.0.0.17, set the file URL for a saved copy of attachment 324105 [details] as the start page, "List Files 1", install Tb 3.0a3 over the top, install Tb 2.0.0.17 over the top, "List Files 2"), but thanks to header and compiler bingo, I no longer have a build environment for 1.8 on Windows, so I can't actually test whether a build-with-my-patch, trunk, build-with-my-patch comes out clean.

Comment 4

[Mark Banner (:standard8)]

I will probably be setting up a 1.8 environment in the next few days/week, so will be able to test for you then.

Comment 5

[Robert Strong (they/them - no direct email)]

Comment on attachment 344244 [details] [diff] [review]
Untested patch

Thanks Phil. The file path delimiter should be forward slashes and not backslashes... it also appears that 
modules/WindowDraggingUtils.jsm is missing.

Comment 6

[Phil Ringnalda (:philor)]

(In reply to comment #5)
> modules/WindowDraggingUtils.jsm is missing.

Yeah, that was another component of "Not sure what to do with this." - I built my list from the Tb3.0a3 release, because that's the only released thing where I'll feel sorry for someone who gets into overwrite trouble, but it's too late for 2.0.0.18 already, but is 3.0b1 going to either ship or code freeze before the code freeze for .19 ... we don't really have a good process for handling "any new file created in a trunk nightly must be listed in a file on the stable branch." (Hmm, how about nsFolderLookupService.js that we shipped for a week in early September?)

Comment 7

[Phil Ringnalda (:philor)]

Wayne: did you actually crash there downgrading, or just copy that change in summary over from the Firefox bug? That particular nsACString_internal::Assign crash had a stack running through brwsrcmp.dll, and was presumably the Firefox 3 feed sniffer doing bad things in a Firefox 2.

Comment 8

[Wayne Mery (:wsmwk)]

philor I no longer remember. I didn't record that I got that crash myself (and crash stats is useless for checking that time period), so I would hope that I had checked crash stats.  However, it's quite possible I copied it from FF.

I am fine with what you feel is most accurate for the summary

Comment 9

[Wayne Mery (:wsmwk)]

do we have a "flip the update from v2" bug that this should block?
or is there thinking this is no longer needed?

Comment 10

[rsx11m]

Is this still an issue? SeaMonkey bug 450504 has been won't-fixed given that the old branches are no longer supported.

Comment 11

[Mark Banner (:standard8)]

Yeah, I don't think we need this one now.