Firefox Social Integration

Please use "Edit with form" above to edit this page.

Status

Firefox Social Integration
Stage	Definition
Status	`
Release target	Firefox 15
Health	OK
Status note	`

{{#set:Feature name=Firefox Social Integration

|Feature stage=Definition |Feature status=` |Feature version=Firefox 15 |Feature health=OK |Feature status note=` }}

Team

Product manager	Asa Dotzler
Directly Responsible Individual	Sheila Mooney
Lead engineer	Mike Hanson
Security lead	Michael Coats
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	Simona Badau
UX lead	Jennifer Morrow
Product marketing lead	`
Operations lead	`
Additional members	Mark Hammond, Shane Caraveo

{{#set:Feature product manager=Asa Dotzler

|Feature feature manager=Sheila Mooney |Feature lead engineer=Mike Hanson |Feature security lead=Michael Coats |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=Simona Badau |Feature ux lead=Jennifer Morrow |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Mark Hammond, Shane Caraveo }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

The Web has become inherently social. The browser is not yet playing a significant role in enabling the social experience. We are going to change that.

Just as we saw search become an integral tool for getting around on the Web and so integrated search touch points into the browser, so has social become an integral part of the Web experience, and that's driving the need for social touch points in the browser.

The first generation of integrating the social experience into Firefox will consist of four touch points.

1. Integration of persistent social notifications into the Firefox toolbar.
2. Integration of news feeds, tickers, buddy lists, etc., into a Firefox sidebar.
3. Integration of chat, voice, video, etc. into docked or floating window.
4. Integration of a share/recommend service in the Firefox toolbar.

With these touch points, users will be able to carry their social presence and tools with them, outside of confines of specific social websites. No longer will users need to be visiting a social provider to share or recommend something within that service, nor will they have to navigate the NASCAR-like mess of social widgets accompanying so much Web content. Users will be able to chat and get updates of various kinds from where ever they happen to be on the Web.

By integrating social into Firefox, Mozilla will put you, instead of any one website, at the center of your social experience.

2. Users & use cases

Users: Firefox users with accounts on social networks.

Use cases:

• A Twitter user is reading a compelling Wikipedia article and would like to share a link to that article with her Twitter followers. Because she's got the new Firefox that features social integration, it's as simple as clicking the share button.

• A Diaspora user is surfing the Web and doesn't want to miss any new posts from his friends back at Diaspora. Firefox has a convenient sidebar where Diaspora sends news updates so he never misses his friends' updates.

• A Google+ user wants to quickly open a chat without chasing down her buried Google+ tab in Firefox. She clicks her buddy's name in the Firefox social sidebar and it pops out a chat Window.

• A Facebook user, just about to hit the 1,000 friends mark doesn't want to miss that incoming friend request. Because he's got Firefox's new social features, he'll get a notification in his Firefox toolbar when any new friend requests, new messages, or notifications arrive.

3. Dependencies

This feature depends on:

1. The Social API back-end implementation
2. UR and UX work to test and design the experience for discovery and enabling social features, each of the 4 social touch points, disabling the social feature, and switching between social providers.
3. Labs and Firefox engineers to implement the front-end of the Social API
4. Social providers to offer up an Open Web Application Manifest - which contains the name, icon, and service data needed for the browser to communicate with the web property.

4. Requirements

• To manage a list of social services (discover, install, delete)
• To display to the user which social services they are currently signed in to
• To easily sign in and out of a service, and to switch which service the user is interacting with, or to switch off social interaction
• To recommend the current page to their friends on a network - either as a standalone URL or with a comment.
• To see which of a user's contacts are online
• To initiate real-time communication with a contact through chat, voice, or video
• To see updates from contacts and to be notified when new updates are available
• To receive, at the user's discretion, ambient or immediate notification when interesting events have occurred

Non-goals

Mixing and matching different parts from different social providers is a non-goal. Users must be able to switch between providers, but it is not required that users be able to display touch points from multiple providers simultaneously.

Stage 2: Design

5. Functional specification

See [1]

The API for social providers is defined in Social API doc and the newsgroup post [groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/1e4048b16c7a6705/7e392549d34e6c62 Proposing some social features for Firefox]

6. User experience design

`

Stage 3: Planning

7. Implementation plan

See the design spec for some thoughts.

A GitHub repo containing a full working implementation of the feature, as an addon, is at [2].

A GitHub repo containing just the backend pieces, is at [3].

8. Reviews

Security review

https://bugzilla.mozilla.org/show_bug.cgi?id=733414

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

Notes from Clint Talbert:

I think we are likely going to need a few different frameworks here before it is all said and done. But focusing on the smaller problem of something that is very developer friendly so that people can run it quickly to write unit tests is the right place to start.

The Test Server

How tough is it to create your test service? It would be great if we could run it locally on the test slaves (or on developer machines) and we could spin it up when we start up the test and shut it down when we're through. Do you need a web server for it? We have two web servers available. The httpd.js [1] is the javascript web server that backs all of mochitest. It is useful because it allows a whole lot of customization so that a test can test poorly behaved (and even incorrect) web server behaviors. It's slow, and it consumes quite a bit of resources.

We have a newer webserver that we are looking at replacing it with. This is a simpler server called mozhttpd and it is part of our wider array of mozbase test harness framework base classes. [2], [3] This server is faster, and is more suited to general purpose web-serving and is unable to do all the configuration stuff that httpd.js can do (although we have a contributor working on those capabilities so we can retire httpd.js one day).

How do you plan to implement the communication between your server and the test itself? That's the part I kept getting hung up on. Most of our testing is quite stateless. The closest thing we have to a stateful testing is TPS (the test system for sync), which runs outside of the main automation trees and uses real servers. It sounds like this is going to have quite a bit of in-browser integration so something that runs outside of the main automation trees while necessary for QA testing, is probably a non-starter if you have to clear Firefox Team review hurdles.

We will want to wire in your test server so that the browser-chrome test framework will start it up for you and keep it running the entire duration of the test run. My team can help wire that into the harness.

The Tests

Likewise, the other thing that I got hung up on with this was the life-cycle nature of these tests. In order for people who aren't you (other devs, QA, etc) we need these to be rather data-driven. Perhaps that means that each test has a large javascript object at the head of the test that details the actions the test will take. Then it should be easy for people to write tests as well as debug tests. You can see how the TPS tests are constructed here: [4].

The other thing I worried about is that with these tests that are essentially using the browser itself as the verification mechanism (i.e. did the button glow blue to indicate server state X?) we run a chance for a whole lot of timing related intermittent issues. It would be awesome if the tests had two modes of verification: 1. Simple Verification Mode: Captures the event that is going to make the button turn blue (this is easier to verify) 2. Complex Verification Mode: Not only does it capture the event, it also ensures that the button did in fact turn blue (this is a little harder and can be prone to causing intermittent orange tests)

If the test is data driven, then the test object can have an attribute stating the type of verification mode it will be using.

Furthermore, this will help streamline the test verification steps into a set of concrete APIs that any given test can use. And that will further simplify test authoring and debugging. (I'm totally making these up, but here are some possible examples of APIs):

• "bool VerifyGoSocialNoticeReceived(int verificationMode)"
• "bool VerifySideBarActivated(int verificationMode)"
• and so on...it would be fine for these verify APIs to write their mochitest pass/fail notice (i.e. they would do the assertion that things are ok or not), so their return value could simply indicate whether we should abort the test at that point or not.

Aborting the test

I think that any long lived test that could cause compounding failures (if we aren't in state 1 we will never make it to state 2, etc) needs to abort early. This way when people go to debugging it, it is clear where we failed and when. So an early abort system should be built into these from the start.

Framework

I think that browser chrome[5] tests are probably the best avenue that we have available for you to use right now. Ideally, Marionette [6] tests would be better simply because then you could drive your test from python scripts so you could ostensibly manage your server (assuming the server can be written quickly and simply in python) and your test from the same code, handling the state checking between test and server in a simple fashion. However, Marionette is not in production yet for desktop firefox (it is for B2G) and we won't have deployed in desktop until sometime in Q3.

So, if you need tests deployed now, I'm thinking that writing a set of JavaScript APIs like I mentioned above to run some data-driven, multi-mode verification tests and calling those from within the browser-chrome framework is probably the way to go. There is quite a bit of precedent for constructing these mini-test-harnesses atop the mochitest framework. Several test directories do this. By being in browser chrome, your actual test files will be javascript, but you will have full control to load pages in the browser, and since your test will operate from chrome you won't have nearly as much headache dealing with security as if you wrote mochitest-plain tests.

And if in the future this proves unwieldy, we can fairly easily switch such a mechanism (self contained javascript tests using mochitest assertions) into marionette tests.

Operations review

`

Stage 4: Development

9. Implementation

List of open issues [4]

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=The Web has become inherently social. The browser is not yet playing a significant role in enabling the social experience. We are going to change that.

Just as we saw search become an integral tool for getting around on the Web and so integrated search touch points into the browser, so has social become an integral part of the Web experience, and that's driving the need for social touch points in the browser.

The first generation of integrating the social experience into Firefox will consist of four touch points.

1. Integration of persistent social notifications into the Firefox toolbar.
2. Integration of news feeds, tickers, buddy lists, etc., into a Firefox sidebar.
3. Integration of chat, voice, video, etc. into docked or floating window.
4. Integration of a share/recommend service in the Firefox toolbar.

With these touch points, users will be able to carry their social presence and tools with them, outside of confines of specific social websites. No longer will users need to be visiting a social provider to share or recommend something within that service, nor will they have to navigate the NASCAR-like mess of social widgets accompanying so much Web content. Users will be able to chat and get updates of various kinds from where ever they happen to be on the Web.

By integrating social into Firefox, Mozilla will put you, instead of any one website, at the center of your social experience. |Feature users and use cases=Users: Firefox users with accounts on social networks.

Use cases:

• A Twitter user is reading a compelling Wikipedia article and would like to share a link to that article with her Twitter followers. Because she's got the new Firefox that features social integration, it's as simple as clicking the share button.

• A Diaspora user is surfing the Web and doesn't want to miss any new posts from his friends back at Diaspora. Firefox has a convenient sidebar where Diaspora sends news updates so he never misses his friends' updates.

• A Google+ user wants to quickly open a chat without chasing down her buried Google+ tab in Firefox. She clicks her buddy's name in the Firefox social sidebar and it pops out a chat Window.

• A Facebook user, just about to hit the 1,000 friends mark doesn't want to miss that incoming friend request. Because he's got Firefox's new social features, he'll get a notification in his Firefox toolbar when any new friend requests, new messages, or notifications arrive.

|Feature dependencies=This feature depends on:

1. The Social API back-end implementation
2. UR and UX work to test and design the experience for discovery and enabling social features, each of the 4 social touch points, disabling the social feature, and switching between social providers.
3. Labs and Firefox engineers to implement the front-end of the Social API
4. Social providers to offer up an Open Web Application Manifest - which contains the name, icon, and service data needed for the browser to communicate with the web property.

|Feature requirements=* To manage a list of social services (discover, install, delete)

• To display to the user which social services they are currently signed in to
• To easily sign in and out of a service, and to switch which service the user is interacting with, or to switch off social interaction
• To recommend the current page to their friends on a network - either as a standalone URL or with a comment.
• To see which of a user's contacts are online
• To initiate real-time communication with a contact through chat, voice, or video
• To see updates from contacts and to be notified when new updates are available
• To receive, at the user's discretion, ambient or immediate notification when interesting events have occurred

|Feature non-goals=Mixing and matching different parts from different social providers is a non-goal. Users must be able to switch between providers, but it is not required that users be able to display touch points from multiple providers simultaneously. |Feature functional spec=See [5]

The API for social providers is defined in Social API doc and the newsgroup post [groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/1e4048b16c7a6705/7e392549d34e6c62 Proposing some social features for Firefox] |Feature ux design=` |Feature implementation plan=See the design spec for some thoughts.

A GitHub repo containing a full working implementation of the feature, as an addon, is at [6].

A GitHub repo containing just the backend pieces, is at [7]. |Feature security review=https://bugzilla.mozilla.org/show_bug.cgi?id=733414 |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=Notes from Clint Talbert:

I think we are likely going to need a few different frameworks here before it is all said and done. But focusing on the smaller problem of something that is very developer friendly so that people can run it quickly to write unit tests is the right place to start.

The Test Server

How tough is it to create your test service? It would be great if we could run it locally on the test slaves (or on developer machines) and we could spin it up when we start up the test and shut it down when we're through. Do you need a web server for it? We have two web servers available. The httpd.js [1] is the javascript web server that backs all of mochitest. It is useful because it allows a whole lot of customization so that a test can test poorly behaved (and even incorrect) web server behaviors. It's slow, and it consumes quite a bit of resources.

We have a newer webserver that we are looking at replacing it with. This is a simpler server called mozhttpd and it is part of our wider array of mozbase test harness framework base classes. [2], [3] This server is faster, and is more suited to general purpose web-serving and is unable to do all the configuration stuff that httpd.js can do (although we have a contributor working on those capabilities so we can retire httpd.js one day).

How do you plan to implement the communication between your server and the test itself? That's the part I kept getting hung up on. Most of our testing is quite stateless. The closest thing we have to a stateful testing is TPS (the test system for sync), which runs outside of the main automation trees and uses real servers. It sounds like this is going to have quite a bit of in-browser integration so something that runs outside of the main automation trees while necessary for QA testing, is probably a non-starter if you have to clear Firefox Team review hurdles.

We will want to wire in your test server so that the browser-chrome test framework will start it up for you and keep it running the entire duration of the test run. My team can help wire that into the harness.

The Tests

Likewise, the other thing that I got hung up on with this was the life-cycle nature of these tests. In order for people who aren't you (other devs, QA, etc) we need these to be rather data-driven. Perhaps that means that each test has a large javascript object at the head of the test that details the actions the test will take. Then it should be easy for people to write tests as well as debug tests. You can see how the TPS tests are constructed here: [4].

The other thing I worried about is that with these tests that are essentially using the browser itself as the verification mechanism (i.e. did the button glow blue to indicate server state X?) we run a chance for a whole lot of timing related intermittent issues. It would be awesome if the tests had two modes of verification: 1. Simple Verification Mode: Captures the event that is going to make the button turn blue (this is easier to verify) 2. Complex Verification Mode: Not only does it capture the event, it also ensures that the button did in fact turn blue (this is a little harder and can be prone to causing intermittent orange tests)

If the test is data driven, then the test object can have an attribute stating the type of verification mode it will be using.

Furthermore, this will help streamline the test verification steps into a set of concrete APIs that any given test can use. And that will further simplify test authoring and debugging. (I'm totally making these up, but here are some possible examples of APIs):

• "bool VerifyGoSocialNoticeReceived(int verificationMode)"
• "bool VerifySideBarActivated(int verificationMode)"
• and so on...it would be fine for these verify APIs to write their mochitest pass/fail notice (i.e. they would do the assertion that things are ok or not), so their return value could simply indicate whether we should abort the test at that point or not.

Aborting the test

I think that any long lived test that could cause compounding failures (if we aren't in state 1 we will never make it to state 2, etc) needs to abort early. This way when people go to debugging it, it is clear where we failed and when. So an early abort system should be built into these from the start.

Framework

I think that browser chrome[5] tests are probably the best avenue that we have available for you to use right now. Ideally, Marionette [6] tests would be better simply because then you could drive your test from python scripts so you could ostensibly manage your server (assuming the server can be written quickly and simply in python) and your test from the same code, handling the state checking between test and server in a simple fashion. However, Marionette is not in production yet for desktop firefox (it is for B2G) and we won't have deployed in desktop until sometime in Q3.

So, if you need tests deployed now, I'm thinking that writing a set of JavaScript APIs like I mentioned above to run some data-driven, multi-mode verification tests and calling those from within the browser-chrome framework is probably the way to go. There is quite a bit of precedent for constructing these mini-test-harnesses atop the mochitest framework. Several test directories do this. By being in browser chrome, your actual test files will be javascript, but you will have full control to load pages in the browser, and since your test will operate from chrome you won't have nearly as much headache dealing with security as if you wrote mochitest-plain tests.

And if in the future this proves unwieldy, we can fairly easily switch such a mechanism (self contained javascript tests using mochitest assertions) into marionette tests. |Feature operations review=` |Feature implementation notes=List of open issues [8] |Feature landing criteria=` }}

Feature details

Priority	P1
Rank	999
Theme / Goal	This feature falls primarily in the Connect space
Roadmap	Firefox Desktop
Secondary roadmap	Sharing
Feature list	Desktop
Project	`
Engineering team	Desktop front-end

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=This feature falls primarily in the Connect space |Feature roadmap=Firefox Desktop |Feature secondary roadmap=Sharing |Feature list=Desktop |Feature project=` |Feature engineering team=Desktop front-end }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	sec-review-needed	bug 733414
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	In progress	Test Plan
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-needed |Feature security health=` |Feature security notes=bug 733414 |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=In progress |Feature qa notes=Test Plan |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}