From http://bugzilla.mozilla.org/show_bug.cgi?id=78374, we should warn the user to restart mozilla, or at least get a new window up before continuing after a theme switch.

putting on 091 radar. Does mozilla want this dialog? If not, we can move this to commercial tree.

nav triage team: There's already a commercial bug logged for this and it's assigned to me. We can keep this open to track mozilla issues.

-> UI:D

This is a dup of bug 75634

Adding self to cc list. I've got a netscape bug to implement this in the netscape tree, and I've got all the patches ready to go. The navigator triage team didn't think it was our place to tell mozilla whether or not to have a dialog; we were just assuming they would like to fix the real problems before mozilla1.0. So I guess the question is: does mozilla want to take the dialog?

*** Bug 75634 has been marked as a duplicate of this bug. ***

talked with asa. not critical for 0.9.1. he thinks we can wait for the right solution.

Bug 78374 says this is a Netscape-only problem, and I can switch themes without incident. So why is this bug here? If this is indeed a Mozilla bug, then instead of using an alert, I suggest putting some warning text (accompanied by a miniature of the confirmation alert icon) under the preview box for the theme. /!\ Changes will not be applied until you restart Mozilla.

->skinability

nav triage team: Don't need a dialog for mozilla, but keeping this bug around just in case. Marking nsbeta1-, p4, and mozilla1.0

Erm, why don't we need the dialog? Switching themes will still nuke the contents of open composer and mail composer windows.

I think the need for this dialog will come and go; things are gonna be changing, sometimes this will work and sometimes it won't. Put it in, and pref it out for a release if things are working. Also note, some skins might be more-working than others, not sure if that is a factor here.

Clearing milestone for reassessment for 0.9.1. To repeat myself, we need this dialog to warn the user of dataloss in open composer and mail compose (and AIM) windows when switching themes.

adding dataloss keyword

Reactivating bug, marking nsbeta1+, there is a bugscape bug about this (5057), but since mozilla is interested in the dialog too now, my new patch is all done in the mozilla source. Will add latest patches now

sr=alecf

adding tpringle@netscape.com to cc list

r=ben@netscape.com I think though if we can't switch themes properly, we should just require a restart, and do as Matthew suggests. That likely requires some toolkit work though.

a= asa@mozilla.org(on behalf of drivers)

let's get this in the 0.9.1 branch now and hold off on the trunk while we discuss it further. Thanks. --Asa

paul pls get this in on the branch. Vishy

Michele - PDT decided that they want this fix. The fix is written such that if it does not find the right strings in the properties file, it will just fail to put up the dialog, but go ahead and do the theme switch without the dialog anyway. You can decide if somehow L10N can get the right strings for the localized builds, or leave as is.

This has been checked in on the branch. Updating status whiteboard

in that case, moving target milestone to m0.9.2.

I do not see a dialog when I try to switch themes using today's (20010606) morning 0.9.1 build.

Checked the build, for some reason, navigator.properties in en-US.jar isn't the version I checked in last night. Hopefully it will get picked up in subsequent builds.

That sounds bad. Can we verify that the build machines are picking up the correct files? We are talking branch builds here, yes?

um - did we fail to update the navigator.properties in the commercial build? we need to try and get this into the next build with the last few new stoppers for m0.9.1 today.

condidate respin already in progress (building mozilla right now). If some files need to be updated in the _ns_ tree, it should happen in the next 30mn so that the ns build will pull them. I looked at the local _mozilla_ tree from this morning and pchen's checkins were picked up.

yeah, I forgot to update the ns version of navigator.properties, so commercial doesn't get the dialog. ooops

This will be picked up by the branch build in progress (2001-06-06-14)

For m0.9.2, we have to take this fix before 6/26 (localization date). Will we be branched before that? If not, can we get approval to take this on the mozilla trunk? thanks.

I don't see any reason not to check the latest warning string into the trunk.. then if we branch after localization freeze, we take the fix on the branch (and the string is already there, waiting to be localized)

-> me, since I can do this as part of my deferal of skin switch

patch in 84344

Fixed.

Verified the patch.