895484 - [SMS] Handle a share URL activity

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Ben Francis [:benfrancis]]

As a user I want to share a URL by SMS

In bug 796565 the browser added a share button which fires a share URL web activity but this activity is not currently handled by any app. Users would like to share a URL by SMS by using this button.

Comment 1

[Borja Salguero [:borjasalguero]]

Hi Ben,
You could use 'new' activity for doing this. In this case you can specify 'phone number' and/or 'body' of the message, so you should use the activity filling only the body with the URL to share (currently 'youtube' sharing is working on this way).
Probably it could be a good idea to add 'share' as a new activity in the manifest, and using the same handler in the code of the SMS App (due to at the end 'new' and 'share' are the same). Can I help you on this issue?

Comment 2

[Ben Francis [:benfrancis]]

(In reply to Borja Salguero [:borjasalguero] from comment #1)
> Hi Ben,
> You could use 'new' activity for doing this. In this case you can specify
> 'phone number' and/or 'body' of the message, so you should use the activity
> filling only the body with the URL to share (currently 'youtube' sharing is
> working on this way).

That doesn't sound right. The browser app doesn't want to create a new SMS, it wants to a share a URL via another app, which could use any method of sharing and doesn't necessarily require creating a "new" anything.

I'm surprised if the YouTube app works in this way because that sounds wrong too.

> Probably it could be a good idea to add 'share' as a new activity in the
> manifest, and using the same handler in the code of the SMS App (due to at
> the end 'new' and 'share' are the same). Can I help you on this issue?

Yes feel free to implement this if you'd like to. The SMS app already handles "share" activities for image/audio/video files so this could be an extension of that, but going through the "new SMS" code path you describe.

Comment 3

[Rick Waldron [:rwaldron]]

(In reply to Ben Francis [:benfrancis] from comment #2)
> (In reply to Borja Salguero [:borjasalguero] from comment #1)
> > Hi Ben,
> > You could use 'new' activity for doing this. In this case you can specify
> > 'phone number' and/or 'body' of the message, so you should use the activity
> > filling only the body with the URL to share (currently 'youtube' sharing is
> > working on this way).
> 
> That doesn't sound right. The browser app doesn't want to create a new SMS,
> it wants to a share a URL via another app, which could use any method of
> sharing and doesn't necessarily require creating a "new" anything.
> 

In the context of the SMS/MMS/Messages app, that's exactly what it means to "share" anything: create a new message with the content that will be shared. Sure, the Messages app can overload the existing "share" activity handler, but that's just unnecessary complexity. 


> I'm surprised if the YouTube app works in this way because that sounds wrong
> too.

It's just sharing a text link, there is nothing surprising about it.


> 
> > Probably it could be a good idea to add 'share' as a new activity in the
> > manifest, and using the same handler in the code of the SMS App (due to at
> > the end 'new' and 'share' are the same). Can I help you on this issue?
> 
> Yes feel free to implement this if you'd like to. The SMS app already
> handles "share" activities for image/audio/video files so this could be an
> extension of that, but going through the "new SMS" code path you describe.

The existing share handler is for sharing _files_ and expects blobs that will be processed into new Attachment objects that will change the new message type from SMS to MMS. Sharing a link is just a new message with a text body that includes a link.

Comment 4

[Jason Smith [:jsmith]]

Adding needinfo on product per productwanted request.

Comment 5

[Ben Francis [:benfrancis]]

(In reply to Rick Waldron from comment #3)
> In the context of the SMS/MMS/Messages app, that's exactly what it means to
> "share" anything: create a new message with the content that will be shared.
> Sure, the Messages app can overload the existing "share" activity handler,
> but that's just unnecessary complexity. 

The whole point of web activities is that the app that fires one doesn't need to know anything about all the possible apps that could consume it. Any app which fires a "share" web activity shouldn't have to care how the consuming app will go about sharing the data it wants to share, just that it wants to share it.

In my opinion this should be a share activity.

Comment 6

[Rick Waldron [:rwaldron]]

(In reply to Ben Francis [:benfrancis] from comment #5)
> (In reply to Rick Waldron from comment #3)
> > In the context of the SMS/MMS/Messages app, that's exactly what it means to
> > "share" anything: create a new message with the content that will be shared.
> > Sure, the Messages app can overload the existing "share" activity handler,
> > but that's just unnecessary complexity. 
> 
> The whole point of web activities is that the app that fires one doesn't
> need to know anything about all the possible apps that could consume it. Any
> app which fires a "share" web activity shouldn't have to care how the
> consuming app will go about sharing the data it wants to share, just that it
> wants to share it.
> 
> In my opinion this should be a share activity.

It doesn't matter to me if it's a "share" or "new", since they will use the same activity handler. I'll take this and when a decision is made, I'll implement.

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

I think the decision has been made that we want a share activity.

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

add to backlog 891754

Comment 9

[Oleg Zasypkin [:azasypkin]]

Hey Rick, are you still going to work on this? If not, please reassign it to me as I'm working on refactoring of share activity right now. Thanks!

Comment 10

[Julien Wajsberg [:julienw]]

Hey Oleg, I think Rick does not have much time to work on this now, so feel free to take it!

Comment 11

[Oleg Zasypkin [:azasypkin]]

Sure :)

Comment 12

[Oleg Zasypkin [:azasypkin]]

Attachment: GitHub pull request URL

Updates:

Current WIP patch. WIP is because it's waiting for base patch (for bug 936729) to be landed.

Comment 13

[Oleg Zasypkin [:azasypkin]]

Hey Julien,

While working on this bug, I've noticed that it's impossible to share mixed content (both video and images at the same batch) from gallery. Presumable it's because of activity data type for that case (multipart/mixed) that we don't define in manifest. 

Is it known constraint?

Comment 14

[Julien Wajsberg [:julienw]]

Yep, I noticed this yesterday too, this is not a constraint from us. Can you file a separate bug? I think this should be fixed at the system level.

Comment 16

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] from comment #14)
> Yep, I noticed this yesterday too, this is not a constraint from us. Can you
> file a separate bug? I think this should be fixed at the system level.

Sure, filed follow-up bug 1001263

Comment 17

[Oleg Zasypkin [:azasypkin]]

Freeing up for now, until bug 1001263 is resolved.

Comment 18

[Julien Wajsberg [:julienw]]

Why does bug 1001263 block you here?

Comment 19

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] from comment #18)
> Why does bug 1001263 block you here?

Well, mainly because of my idea for this patch. See patch https://github.com/mozilla-b2g/gaia/pull/18563/files#diff-c4a4a1fb8874a8e40d0ebec5b8047224R123

I use 'switch' here to respect activity data type, that breaks current unit tests for ActivityHandler (mock for shareActivity where I should add type as gallery does - 'multipart/mixed' to make it work).

But as per your comment 14 it should be fixed on system level, not just by adding 'mulitpart/mixed' to manifest. So I'm not sure how to proceed with this patch until I know how to deal with multipart/mixed.

Of course I can cheat in tests and add some of the known types to shareActivity mock, but it doesn't feel right.

What do you think?

Comment 20

[Julien Wajsberg [:julienw]]

I have 2 suggestions for you:
* special case "ActivityDataType.URL" and add all others as attachments
* test on the blob's type instead of the activity type

What do you think?

Comment 22

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] from comment #20)
> I have 2 suggestions for you:
> * special case "ActivityDataType.URL" and add all others as attachments
> * test on the blob's type instead of the activity type
> 
> What do you think?

I think probably #1 may be acceptable solution at least until we hear something new from Fabrice on bug 1001263.

Don't really like #2 as we need to take care of too many subtypes (different image/video types).

Comment 23

[Julien Wajsberg [:julienw]]

(In reply to Oleg Zasypkin [:azasypkin] from comment #22)
> (In reply to Julien Wajsberg [:julienw] from comment #20)
> > I have 2 suggestions for you:
> > * special case "ActivityDataType.URL" and add all others as attachments
> > * test on the blob's type instead of the activity type
> > 
> > What do you think?
> 
> I think probably #1 may be acceptable solution at least until we hear
> something new from Fabrice on bug 1001263.
> 
> Don't really like #2 as we need to take care of too many subtypes (different
> image/video types).

You can match on "image/.*" and "video/.*" :)

Comment 24

[José Antonio Olivera Ortega [:jaoo]]

Bug 1001876 has been marked as a duplicate bug of this one and after having a look at the WIP patch I would like to request -if it's possible- the sms app to accept the phone number of the end party when sharing the URL. The use case for the Loop client is -more or less- to share the 'call URL' with the called party and we already know its phone number (MSISND) so it would save the caller to insert the phone number again. Would it be possible? Thanks!

Comment 25

[Julien Wajsberg [:julienw]]

José, is there a reason you can't use the "new" activity for this? In my opinion, the "share" activity should be compatible with email, and I don't see using a phone number being good for this. Or should we take a full contact instead?

Comment 26

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] from comment #23)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #22)
> > (In reply to Julien Wajsberg [:julienw] from comment #20)
> > > I have 2 suggestions for you:
> > > * special case "ActivityDataType.URL" and add all others as attachments
> > > * test on the blob's type instead of the activity type
> > > 
> > > What do you think?
> > 
> > I think probably #1 may be acceptable solution at least until we hear
> > something new from Fabrice on bug 1001263.
> > 
> > Don't really like #2 as we need to take care of too many subtypes (different
> > image/video types).
> 
> You can match on "image/.*" and "video/.*" :)

Yeah, we can solve any problem in a variety of ways :) I just meant that in case of checking blob type we should check it for EVERY attachment that is being shared. In this case why can't we accept multipart/mixed then, if we check type for every blob anyway :) 

If we rely on blob type only for the first item from the set and make assumption that the rest also has the same type - IMO it will look confusing and not natural.

Comment 27

[Julien Wajsberg [:julienw]]

(In reply to Oleg Zasypkin [:azasypkin] from comment #26)
> (In reply to Julien Wajsberg [:julienw] from comment #23)
> > (In reply to Oleg Zasypkin [:azasypkin] from comment #22)
> > > (In reply to Julien Wajsberg [:julienw] from comment #20)
> > > > I have 2 suggestions for you:
> > > > * special case "ActivityDataType.URL" and add all others as attachments
> > > > * test on the blob's type instead of the activity type
> > > > 
> > > > What do you think?
> > > 
> > > I think probably #1 may be acceptable solution at least until we hear
> > > something new from Fabrice on bug 1001263.
> > > 
> > > Don't really like #2 as we need to take care of too many subtypes (different
> > > image/video types).
> > 
> > You can match on "image/.*" and "video/.*" :)
> 
> Yeah, we can solve any problem in a variety of ways :) I just meant that in
> case of checking blob type we should check it for EVERY attachment that is
> being shared. In this case why can't we accept multipart/mixed then, if we
> check type for every blob anyway :) 

The difference is that if we accept multipart/mixed, the SMS app would be proposed in the list of apps when the user tries to "share" such objects, even if some objects are not correct. Which might be acceptable or not, by the way.

> 
> If we rely on blob type only for the first item from the set and make
> assumption that the rest also has the same type - IMO it will look confusing
> and not natural.

Yep we should not do this because once the system app is fixed in bug 1001263 it will happen that we have different types.

Comment 28

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] from comment #27)
> The difference is that if we accept multipart/mixed, the SMS app would be
> proposed in the list of apps when the user tries to "share" such objects,
> even if some objects are not correct. Which might be acceptable or not, by
> the way.

Yeah, that's true.

Comment 29

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8410852 [details] [review]
GitHub pull request URL

Ok, let's try to proceed with this patch as it's not clear when bug 1001263 is going to be resolved :)

Note: I've removed multipart/mixed handling and left "switch" based on enum just to be more expressive on what data types we actually can process. At the same time I don't mind to make it simpler (eg. just "if\else" instead of "switch"), just Let me know what you prefer and I take care of it :)

+ Added support for activity.postError inside leaveActivity.

Comment 30

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Julien Wajsberg [:julienw] from comment #25)

FYI Loop call URLs must be shared through both the SMS and the email app. The email app already shared them.

> José, is there a reason you can't use the "new" activity for this? 

Yes, there is. IMHO it doesn't make sense to use to different activities. The 'new' one when sharing URLs through the SMS app and the 'share' one when sharing them through the Email app. Moreover using different activities for it forces the Loop app to implement the confirm dialog for choosing the app to handle the action and IMHO it should be avoided.

> In my
> opinion, the "share" activity should be compatible with email, and I don't
> see using a phone number being good for this.

I agree with you but AFAIK adding the phone number to the data for the 'share' activity doesn't involves big changes (please, correct me if I am wrong).

> Or should we take a full
> contact instead?

(I guess) That would be another possibility. Let me confirm this please.

Comment 31

[Julien Wajsberg [:julienw]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #30)

> > Or should we take a full
> > contact instead?
> 
> (I guess) That would be another possibility. Let me confirm this please.

Without this, you'll still need to know what is the target of your activity, because you'll need to know whether you need to pass a phone number or an email.

Passing a full contact ("full" means "correct structure" in my mind, it does not need to have all informations) makes more sense.

Comment 32

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Julien Wajsberg [:julienw] (away until 5th May) from comment #25)
> José, is there a reason you can't use the "new" activity for this?

Yes, the idea is to provide an UX where the user can *share* an URL without making the app UI explicit about the sharing mechanism to use. We don't want two (or many) buttons, one for sharing via email ("share") and another one for sharing via sms ("new"). We want one button to share and the mozActivity implementation showing the selection menu to allow the user to choose the allowed sharing mechanisms. One button triggering the "share" activity scales, one button triggering an specific activity per sharing mechanism doesn't really scale.

> In my
> opinion, the "share" activity should be compatible with email, and I don't
> see using a phone number being good for this.

Why would you want an email in SMS? Is it because MMS can be sent to emails?

If that's the case, the SMS app should specify in its filter that it requires a phone number and/or an email to send the SMS (as it does in "new"). If that is not the case, it should specify in its filter that it requires a phone number.

You cannot send an SMS/MSS without the phone number (or the email if the MMS allows emails which I am not sure).

> Or should we take a full
> contact instead?

I don't think that would work ok. If you mean specifying in the filter that "share" with SMS/MMS requires a contact, then what happen with contacts without phone numbers (or maybe emails if MMS allows emails)? That will provide a wrong UX where the user will be given the option to share via SMS/MMS even if there is no information about the receptor of the SMS/MMS (phone number and/or email).

What I believe SMS should do is specifying what it needs from the activity caller to share something via SMS/MMS and that is a phone number (and maybe an email), but not a contact, which might not have these values.

Comment 33

[Julien Wajsberg [:julienw]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #32)
> (In reply to Julien Wajsberg [:julienw] (away until 5th May) from comment
> #25)
> > José, is there a reason you can't use the "new" activity for this?
> 
> Yes, the idea is to provide an UX where the user can *share* an URL without
> making the app UI explicit about the sharing mechanism to use. We don't want
> two (or many) buttons, one for sharing via email ("share") and another one
> for sharing via sms ("new"). We want one button to share and the mozActivity
> implementation showing the selection menu to allow the user to choose the
> allowed sharing mechanisms. One button triggering the "share" activity
> scales, one button triggering an specific activity per sharing mechanism
> doesn't really scale.
> 
> > In my
> > opinion, the "share" activity should be compatible with email, and I don't
> > see using a phone number being good for this.
> 
> Why would you want an email in SMS? Is it because MMS can be sent to emails?

I meant: "compatible with the E-mail app activity".

Can I see a sample code that you use for launching the "share" activity ? That will probably clear up my questions :)

Comment 34

[Oleg Zasypkin [:azasypkin]]

Just two quick questions from my side as I don't really know much about Loop client:

* what is the exact relationship between url and phone number that being send together via share activity?

* if both are required for Loop, why don't you use some more specific activity type like 'loop-url'?

Comment 35

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Julien Wajsberg [:julienw] (away until 5th May) from comment #33)
> (In reply to Fernando Jiménez Moreno [:ferjm] from comment #32)
> > (In reply to Julien Wajsberg [:julienw] (away until 5th May) from comment
> > #25)
> > > José, is there a reason you can't use the "new" activity for this?
> > 
> > Yes, the idea is to provide an UX where the user can *share* an URL without
> > making the app UI explicit about the sharing mechanism to use. We don't want
> > two (or many) buttons, one for sharing via email ("share") and another one
> > for sharing via sms ("new"). We want one button to share and the mozActivity
> > implementation showing the selection menu to allow the user to choose the
> > allowed sharing mechanisms. One button triggering the "share" activity
> > scales, one button triggering an specific activity per sharing mechanism
> > doesn't really scale.
> > 
> > > In my
> > > opinion, the "share" activity should be compatible with email, and I don't
> > > see using a phone number being good for this.
> > 
> > Why would you want an email in SMS? Is it because MMS can be sent to emails?
> 
> I meant: "compatible with the E-mail app activity".

I think we would still be "compatible" with the email app "share" activity. The fact that the SMS app expects a phone number within the given activity data does not affect the email app. The email app filter is not exclusionary about that.

Correct me if I am wrong please, but I believe that a new mozActivity({ name: "share", data: { type: "url", url: "http://whatever", number: "[phone]" }}); will still list the email app as one of the possible activity handler options.

I believe there are two things to do here:

1- Handle the 'number' field contained within the activity data in the SMS "share" activity handler. If the activity caller knows it and it is giving it, we should use it.

2- Decide if we want to allow the SMS app to handle a "share" activity even if the activity caller is not providing a phone number. This is probably a product call.

> Can I see a sample code that you use for launching the "share" activity ?
> That will probably clear up my questions :)

https://github.com/jaoo/firefoxos-loop-client/blob/988396/js/controller.js#L36

Comment 36

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Oleg Zasypkin [:azasypkin] from comment #34)
> Just two quick questions from my side as I don't really know much about Loop
> client:
> 
> * what is the exact relationship between url and phone number that being
> send together via share activity?
>

No relationship at all other than the phone number owner being the one that is supposed to receive the URL.

> * if both are required for Loop, why don't you use some more specific
> activity type like 'loop-url'?

We potentially want to be able to share the generated Loop URLs via any of the "share" mechanisms that are available. So far the product specs only mention SMS and email as mandatory sharing mechanisms (mostly because these are core apps and should be the minimum set of sharing options), but this should be extensible to any other "share" handler. For example, if the user installs a Facebook app and this app exposes a "share" activity, we want it to be part of the list of options that the user can use to share Loop URLs. I believe the Twitter app already implements the "share" activity so that would be another example.

Comment 37

[Oleg Zasypkin [:azasypkin]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #36)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #34)
> > Just two quick questions from my side as I don't really know much about Loop
> > client:
> > 
> > * what is the exact relationship between url and phone number that being
> > send together via share activity?
> >
> 
> No relationship at all other than the phone number owner being the one that
> is supposed to receive the URL.

Got it, thanks!

> > * if both are required for Loop, why don't you use some more specific
> > activity type like 'loop-url'?
> 
> We potentially want to be able to share the generated Loop URLs via any of
> the "share" mechanisms that are available. So far the product specs only
> mention SMS and email as mandatory sharing mechanisms (mostly because these
> are core apps and should be the minimum set of sharing options), but this
> should be extensible to any other "share" handler. For example, if the user
> installs a Facebook app and this app exposes a "share" activity, we want it
> to be part of the list of options that the user can use to share Loop URLs.
> I believe the Twitter app already implements the "share" activity so that
> would be another example.

Sorry, I meant using 'share' activity, but using data type other than 'url' something like 'loop-url'. One thing that bothers me is that other apps that accepts 'url' via share activity will have access to data (phone number) that isn't intended for it and for example may accidentally leak it. Or it's not the case?

Comment 38

[Borja Salguero [:borjasalguero]]

> Sorry, I meant using 'share' activity, but using data type other than 'url'
> something like 'loop-url'. One thing that bothers me is that other apps that
> accepts 'url' via share activity will have access to data (phone number)
> that isn't intended for it and for example may accidentally leak it. Or it's
> not the case?

Hi Oleg. In this case, the action is to 'share' an 'url' taking into account an specific identification (phone number or email), and we should keep it as simple as it seems. It's the responsibility of each app which offers 'share' activity in it manifest to control the params of 'data' needed. When we delegate an activity, is the app which receives the data the one in charge of handling it, and there are scenarios that we can not control.

Imagine, for example, an App which is able to share pictures with a maximum of 1MB, and you are passing a blob bigger than that. Imagine that you are in the Gallery app, and you decide to 'share' a picture of 3MB. The size is not in the 'data' of the activity [1], so our App will be in the list. If we choose this App, we are going to send the 'blob' and we are going to retrieve a postError (or even worst, depending on how the App is handling the error here). If the app fails because of this, it's a bug in the App, not in the Gallery. This is the same scenario here. We want more apps for sharing an url in the marketplace (we dont want to be tied to any custom param as 'loop-url', because we are sharing a regular url, not a special one), and we want to use them in Loop. We can not ensure that all these apps handle phone number/email in the right way, but we need to ensure that SMS App (email as well) is working as expected.

So in our case, we should accept video, image, text, url and/or a phone number. With this we are covering all the scenarios (due to mixed content will be part of [2]). Adding a contact is adding more complexity which is not needed here, due to not all the apps have access to contacts (actually only a few). So I would like to keep it simple, adding 'sharing an url' by phone number in SMS App.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/gallery/js/gallery.js#L1199
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1001263

Comment 39

[Julien Wajsberg [:julienw]]

> Adding a contact is adding more complexity which is not needed here, due to not all the apps have access to contacts (actually only a few).

We could still have an object in a contact-like format, using the same field. Or would you rather have 2 fields in the activity data?

I just want to say I'm not against the idea of extending the "share" moz activity, I only want to understand what's needed.

Comment 40

[Julien Wajsberg [:julienw]]

Ferjm, I think it makes sense to start a discussion in the webapi mailing list, to have a good solution. Remember the "share" activity will be able to be used by anybody so it's important to make it right. Can you handle this?

Comment 41

[Julien Wajsberg [:julienw]]

Comment on attachment 8410852 [details] [review]
GitHub pull request URL

Current patch looks good.

Ferjm, we can either land this patch now and open a follow-up for the loop requirements, or wait that we have a good solution for this. What do you prefer?

Comment 42

[Fernando Jiménez Moreno [:ferjm]]

Yes, I guess we can land this one and add the number in a follow-up. Thanks.

Comment 43

[Julien Wajsberg [:julienw]]

Comment on attachment 8410852 [details] [review]
GitHub pull request URL

r=me then

let's file a follow-up for what Loop needs, and discuss on dev-webapi about the best way to convey the data you need.

Comment 44

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] from comment #43)
> Comment on attachment 8410852 [details] [review]
> GitHub pull request URL
> 
> r=me then
> 
> let's file a follow-up for what Loop needs, and discuss on dev-webapi about
> the best way to convey the data you need.

Filed follow-up bug 1009550 that blocks Loop Client <-> Gaia integration instead of this one.

Comment 45

[Oleg Zasypkin [:azasypkin]]

Ok, I've fixed "errorReason" nit and Travis is green!

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Master: https://github.com/mozilla-b2g/gaia/commit/b601a9fa772df06b136c5651dc21fe05947d9036

Comment 47

[pete siphantong [:Petes]]

This issue still occurs on the flame 2.0


2.0 Environmental Variables:
Device: Flame 2.0 
BuildID: 20140527040202
Gaia: 6a391274cd436f8f0d1fad2db8c6b4805703259c
Gecko: cbe4f69c2e9c
Version: 32.0a1
Firmware Version: v10g-2

Comment 48

[Julien Wajsberg [:julienw]]

Can you please share your STR?

Comment 49

[pete siphantong [:Petes]]

1. Go to Browser 
2. Go to a site, ex. google.com
3. Tap the share icon

Notes: the user does not have a share sms option, just the e-mail

Comment 50

[Maria Angeles Oteo (:oteo)]

In latest master build on my buri is working fine and the SMS option is shown together with the e-mail.

B-180
Gecko-4a08636
Gaia-eca8a38

Comment 51

[Julien Wajsberg [:julienw]]

How do you flash your Flame?
Can you try to rehash your manifest files?
You can do that using my script in [1] and run it using:
  addpref rehash-manifest

[1] https://github.com/julienw/config-files/blob/master/addpref

Thanks

Comment 52

[pete siphantong [:Petes]]

My mistake I was on 1.4 instead of 2.0, this issue does not occur on the flame 2.0


2.0 Environmental Variables:
Device: Flame 2.0 
BuildID: 20140527040202
Gaia: 6a391274cd436f8f0d1fad2db8c6b4805703259c
Gecko: cbe4f69c2e9c
Version: 32.0a1
Firmware Version: v10g-2

Comment 53

[Julien Wajsberg [:julienw]]

Great, thanks!

So it's verified?

Comment 55

[vsireesha246]

Would you please rebase with this patch and provide me the patch for V1.4.
This bug patch is not applied in V1.4.

Comment 56

[Julien Wajsberg [:julienw]]

I'm afraid this patch depends on other patches, and in the end it's really risky to make it work properly in v1.4 without regressions. I'd rather not take the risk.

I think we can probably make a safe v1.4-specific patch for this (as the main issue is easy to fix: properly handle "url" mime type while not regressing the other mime types) but I won't work on it unless this bug has a blocker status.