Should be able to display tour notification based on the request sent from the back-end server. This includes - what type to display - when to display

Fischer do we still need implement it, or we just need to set a pref and left the server notification stuff for activity-stream?

(In reply to Fred Lin [:gasolin] from comment #1) > Fischer do we still need implement it, or we just need to set a pref and > left the server notification stuff for activity-stream? Maybe we could use a pref like - "browser.onboarding.newUserTourIds = sync,addons,privateWindow" and - "browser.onboarding.updateUserTourIds = singleSearch,addons,privateWindow". For example of "browser.onboarding.newUserTourIds = sync,addons,privateWindow", it means - 3 tours in New User Tour - they are sync, addons, privateWindow tour - their order (top to bottom) in the overlay is sync, addons, privateWindow - their order (first to later) in the notification is sync, addons, privateWindow Above is the rough ideal.

Francis, since the actual server control plan is not clear now and not affect v57 at all, should we de-prioritize this issue?

hi Cindy, please comment on this bug, my opinion is: this should be a P3 for now.

This is considered a meta bug for all the notification logic. I'll mark this as P3 but Michael can you file a bug to list the 1st version of the tour logic that we talked about this week? A time-based logic to define when each tour will appear. Thanks! Cindy

(In reply to chsiang from comment #5) > This is considered a meta bug for all the notification logic. > I'll mark this as P3 but Michael can you file a bug to list the 1st version > of the tour logic that we talked about this week? > A time-based logic to define when each tour will appear. > > Thanks! > Cindy Thanks, Cindy. Update the title as well.

(In reply to chsiang from comment #5) > Michael can you file a bug to list the 1st version > of the tour logic that we talked about this week? > A time-based logic to define when each tour will appear. I added that here Bug 1357668 comment5

I think we can close it since this feature is delegate to snippet, right?

(In reply to Fred Lin [:gasolin] from comment #8) > I think we can close it since this feature is delegate to snippet, right? It depends on the tours order. The bug 1375775 introduced 2 prefs: "browser.onboarding.newtour" and "browser.onboarding.updatetour" to set the tours to show and the order. Since the notifications follow the tours, the bug 1375775 fulfilled the requirement of this bug. Duplicate it.

Make it clearer. All the prefs for controlling. (In reply to Fischer [:Fischer] from comment #0) > Should be able to display tour notification based on the request sent from > the back-end server. > This includes > - what type to display Fulfilled by the bug 1375775: "browser.onboarding.newtour" and "browser.onboarding.updatetour" > - when to display Fulfilled by the bug 1372067: - "browser.onboarding.notification.mute-duration-on-first-session-ms": the mute duration for notifications on the 1st session. In ms, 5 mins currently. - "browser.onboarding.notification.max-life-time-per-tour-ms": the max life time for one notification if no user interaction. In ms, 5 days currently. - "browser.onboarding.notification.max-prompt-count-per-tour": the max impressions for one notification if no user interaction. 8 impressions currently.