(Quoting rsx11m from bug 840474 comment #19) > Note that bug 856454 will provide a UI for the associated preferences in the > Notifications pane with SeaMonkey 2.20; if the new alert remains off until > then, those will have to be hidden to avoid user confusion. > > If mail.biff.show_new_alert will stay even after the new alert if finalized, > it may be a good idea either way to let visibility of those prefs depend on > its value.
Created attachment 752766 [details] [diff] [review] Proposed patch This is the least intrusive way to make the additional options hide when the new alert is switched off, thus the UI should be safe for further releases shipped with the old alert selected by default. It should also be easy to be backed out again if the old code ever gets removed (restricted to a single block of code in a single file and easily searchable by the preference name). As written, an exception is thrown in Startup() if the pref does no longer exist, thus it should be easily discoverable if missed. Sure, it would be nicer to combine the checkboxes in a vbox and hide that box rather than the individual prefs, but that would imply changes in the XUL part and may result in a redundant vbox if mail.biff.show_new_alert gets removed. No conflict with bug 872133 attachment 749385 [details] [diff] [review], thus both patches can be reviewed and pushed independently.
BTW: alerts.totalOpenTime should apply also for the old notifications, thus I'm not touching it (and it would be tricky string-wise anyway).
Thanks for the reviews, push for comm-central please.
Comment on attachment 752766 [details] [diff] [review] Proposed patch [Approval Request Comment] Regression caused by (bug #): Follow-up fix to bug 856454 User impact if declined: SeaMonkey 2.20 would have a different behavior / UX Testing completed (on m-c, etc.): tested and works fine with 2.20 Risk to taking this patch (and alternatives if risky): low String changes made by this patch: none