When bug 1001625 lands, we can create a settings to activate the settings drawer and the new notification (Let's call it `settings-drawer-notifications.enabled`). This setting will be set to true when the HAIDA build flag is enabled. Would be cool to activate it from the developers tool to allow testing before going live.

This is a separate PR as it's needed by both the settings drawer and the new notifications. It does nothing more than creating a new setting called settings-drawer-notifications.enabled (pretty verbose, feel free to propose a better name). I also added an option to enable it from the developer menu (Rocketbar should be added there too). Yuren, can you please review it? I saw you reviewed bug 1001625 and this one is very similar.

This PR is very trivial, so anybody with time, please review it.

Comment on attachment 8418129 [details] Github PR This looks good to me. To be honest though, I would generally prefer to wait to land this until we have a feature that is using this. Though assuming that Yuren reviews this it's probably not too bad to land this for now.

I agree with you it's a bit weird to land a settings that does nothing. But that's easier for me and Mike, as both our code needs this, to land it beforehand.

Sure, but the beauty of github is that you can pull any commit into your branch from any other branch so everything will work :) Anyway - it's definitely easier working off master though, so if you guys will be landing stuff in 2.0 we should get it in. Also - I guess one question I would ask is why do we have one setting for settings drawer and notifications? Any particular reason it should not be or can't be two different settings?

Comment on attachment 8418129 [details] Github PR LGTM. Let's make sure we get Yuren to r+ too before landing. (In reply to Kevin Grandon :kgrandon from comment #7) > Also - I guess one question I would ask is why do we have one setting for > settings drawer and notifications? Any particular reason it should not be or > can't be two different settings? If you enable the settings drawer, you lose the real estate in the utility tray where the notifications used to go. So these things really have to be toggled together.

(In reply to Michael Henretty [:mhenretty] from comment #8) > If you enable the settings drawer, you lose the real estate in the utility > tray where the notifications used to go. So these things really have to be > toggled together. Sure, but the settings drawer is invoked when you tap on the statusbar icons, correct? The utility tray is only invoked when you pull down from the statusbar. In an ideal world, these listeners would not depend on each other, so you should be able to have a settings drawer and a notifications tray if you really wanted depending on the user gesture.

(In reply to Kevin Grandon :kgrandon from comment #9) > Sure, but the settings drawer is invoked when you tap on the statusbar > icons, correct? The utility tray is only invoked when you pull down from the > statusbar. In an ideal world, these listeners would not depend on each > other, so you should be able to have a settings drawer and a notifications > tray if you really wanted depending on the user gesture. Yeah, that's a good point. In my head, the settings drawer replaced utility tray, but I guess there is nothing from a UI or code perspective that prevents having both at the same time (except arguably bad UX). Guillaume, I appreciate you adding this setting for my notification work too, but it probably makes more sense to have separate settings for each feature. Can you modify your PR to only apply to settings drawer?

Comment on attachment 8418129 [details] Github PR sorry for reviewing it late, build script part looks good, r=yurenju

I changed the code to use the settings drawer next to the utility tray. It's not pretty mainly because of an overlapping issue, but one is closed when the other opens and vice versa. So that works. In this case, we don't need that issue anymore as the code will go into Bug 924586.