(tested on ftp trunk and ftp branch nightlies, on a fresh profiles)
1. Start up Calendar.
2. Create a new event.
3. Type something in the description.
4. Decide to quit the app.
Two results for procedure #4:
if cmd-Q is pressed, a confirmation dialog (asking to save or not) is brought up.
if the mouse is used, (-> Calendar -> Quit Calendar), no dialog is brought up asking to save the data.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:220.127.116.11pre) Gecko/20080115 Calendar/0.8pre
Still occurs in today's branch build. (Today's trunk build fails to mount) Nominating blocking-calendar0.8 since this is potential dataloss.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008011503 Calendar/0.6a1
Occurs in trunk build as well. (Apologies; I had a download error previously, re-downloaded and all was ok)
reproduced on Windows XP (nightly thunderbird and lightning en-US branch builds dated 20080123).
Two results' procedure after typing something in the description:
Works correctly (save event dialog comes up) if control-Q is pressed at the event window. And if mouse is used to go File -> Exit at the event window.
Works incorrectly (save event dialog does not come up) if control-Q is pressed at the Thunderbird main UI or if mouse is used to go File -> Exit at the Thunderbird main UI.
This does not block the 0.8 release.
Created attachment 405747 [details] [diff] [review]
Fix - v1
This was quite an easy one, who would have thought! We should think about changing the "do you want to save this event" message to include the event title, i.e when the user has a bunch of events open. Since we are in string freeze, we should think about doing that in a new bug though.
Comment on attachment 405747 [details] [diff] [review]
Fix - v1
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/6d23d73b8849>
and comm-1.9.1 <http://hg.mozilla.org/releases/comm-1.9.1/rev/0bfb80db129e>
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/20100224 Calendar/1.0b2pre
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".