796565 - Share URL of web page

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect, P1)

Description

[GH to BZ]

[GitHub issue by nhirata on 2012-08-28T22:17:49Z, https://github.com/mozilla-b2g/gaia/issues/4058]
## Environment :
Otoro phone, build 2012-08-28
Taken from default.xml in b2g-distro: 
* "platform_build" revision= 76e88b579737d7b5078063dcbec60c2ad2c70465
* "gaia" revision= b3826df518b6df1bd8183333a3c1fe0cb96bd440 
* "mozilla-central" revision= b7fb1238bedd2d419e2c86ce221da53c531ebb3a
* "gonk-misc" revision= a9b6133e492017d34703ae3f24ea1fa9349cbcce

## Repro :
1. launch browser


## Expected :
1. there should be a paper airplane icon to share with Email, Facebook, Messaging, Twitter

## Actual :
1. no paper airplane icon

## Note :

Comment 1

[GH to BZ]

[GitHub comment by nhirata on 2012-08-28T22:19:11Z]
listed as a requirement.

Comment 2

[GH to BZ]

[GitHub comment by benfrancis on 2012-08-29T15:45:31Z]
Where is this listed as a requirement? It's been dropped for v1. Please see the browser app page of the product backlog for v1 requirements https://docs.google.com/a/tola.me.uk/spreadsheet/ccc?key=0AiBigu584YY7dGlNSlY0QzhJb3M5anRBa1gxalV0Y3c#gid=9

Note that the wiki page is not in sync with the backlog & github.

Comment 3

[GH to BZ]

[GitHub comment by lco on 2012-08-29T16:59:16Z]
AFAIK, it has been dropped for v1. @cleemoz for confirmation

Comment 4

[GH to BZ]

[GitHub comment by cleemoz on 2012-08-29T19:54:51Z]
Correct, this was moved out of v1.

Comment 5

[GH to BZ]

[GitHub comment by nhirata on 2012-08-29T20:05:30Z]
Marking for v2.

Comment 6

[Ben Francis [:benfrancis]]

User story: As a user I want to share the URL of a web page I'm viewing

UX: If we want this for 1.2, we already have an interaction design so all we really need is the share icon asset and we can go ahead and implement it.

Comment 7

[Stephany Wilkes]

Ben, we are planning to work on a larger sharing pattern for 1.2. I can include this bug in that.

Comment 8

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/10702

Submitting work in progress patch for feedback.

* This is only the browser part, we will need other apps to consume the share web activity. Right now only Bluetooth sharing does this, badly.
* I've also refactored some code by starting to split out the toolbar-related code with a view to making the browser code more modular.
* I expect this to spark a discussion about how to go about re-factoring (how to split up the app, one big re-factor vs. a bit at a time, dedicated refactoring bugs etc.) I thought I'd take the out of character step of starting the discussion with code rather than a long email :)
* This will probably have merge conflicts with one of the patches Dale is working on.

Comment 9

[Dale Harvey (:daleharvey)]

I think any refactoring though should be done alongside writing tests for the particular functionality, we have been lax on tests and its beginning to show through in terms of regressions. In fact I wouldnt count refactoring as a task or a bug at all, just a side effect of having more testable code.

The patch looks good, it seems like if we are going to use it as an example of improving our workflow we should look into how to test it (I am mostly certainly against merging any refactors without tests)

Comment 11

[Ben Francis [:benfrancis]]

Apparently the UX spec is here http://people.mozilla.com/~lco/FX_B2G/Release_1_Specs/R1_Sharing_v1.pdf

Comment 12

[Karen Rudnitski [:kar]]

Acceptance Criteria: follows the UX spec

Comment 13

[Ben Francis [:benfrancis]]

Comment on attachment 769119 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/10702

Updated patch to resolve merge conflicts and play nicely with bug 814506

Comment 14

[Dale Harvey (:daleharvey)]

Comment on attachment 769119 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/10702

Codewise this is good, there is always going to be race between the activity being landed and the receiver, so happy about this landing prior to being supported before recievers are implemented (it also mean that other apps can build a receiver)

Can you open bugs to communicate to the bluetooth / email etc teams that this is now being broadcast by the browser.

Will follow up with the test plans

Comment 15

[Dale Harvey (:daleharvey)]

Merged in: https://github.com/mozilla-b2g/gaia/commit/d31cd1e6c97fbe0ed21dcd8f132e1516156a5ad8

Comment 16

[Dale Harvey (:daleharvey)]

Test plan for this is to install a test app that registers a receiver for the url share activity, then have marionette visit a url, press the share button and the test reciever verify the data transferred in the activity

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Here's a Boilerplate to test web activities.

http://robnyman.github.io/Firefox-OS-Boilerplate-App/

Comment 18

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

bug 896945 blocks testing when the browser app is open ( see bug 897180 )

Comment 19

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Note: this shares out via Bluetooth only.  I think we need to fix this so that email, sms, and other web applications (twitter, facebook) see this as well.

Comment 20

[Karen Rudnitski [:kar]]

I've been having a real pain in trying to get updated builds onto my devices, an issue I'm trying to resolve in parallel. But in the meantime, Ian had a look at this and let me summarize.

It looks like the 'share' icon has been implemented as expected and it does work. This bug appears to add code that *enables* users to share via supported shared intents. Taking this guidance, this bug does do that.

It is assumed that this bug does *not* take into account the actual plugging in of other intents and that relies on other code from other teams. Therefore once other intents are available, we will need this tested to ensure that folks can share as expected.

Finally, it is also assumed that we will not just be shipping with 'one' supported shared intent (in this case, Bluetooth). Otherwise the UI is a bit weird to 'choose' from a list of 1. But I am assuming that by the time we ship, at least one other intent should be supported and therefore visible in this list.

Ben - is it possible for you to validate my assumptions? If what I'm saying makes sense, I can then accept this feature in Pivotal Tracker.

Comment 21

[Ben Francis [:benfrancis]]

Your assumptions are correct, this bug just covers the browser part, the SMS and email apps have separate bugs to actually handle the web activity. Also, the selection between multiple web apps to handle a web activity only appears if there are multiple apps to choose from.

Comment 22

[Karen Rudnitski [:kar]]

great - feature accepted in pivotal tracker due to confirmation of the assumptions made!