Closed Bug 821519 Opened 9 years ago Closed 8 years ago

[B2G][Email] Unable to share webpage to email


(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:koi+, b2g18-, b2g-v1.2 verified)

1.2 FC (16sep)
blocking-b2g koi+
Tracking Status
b2g18 - ---
b2g-v1.2 --- verified


(Reporter: rbillings, Assigned: gaye)



(Keywords: productwanted)


(1 file)

Users are unable to share a webpage to an email client. This is based on the use case EMAIL-098 and the moztrap test case listed below.

EMAIL-098	As a user I want to initiate composing a message from other applications on the phone so that I can easily share ideas at anytime without having to go through multiple screens to start sharing.
For v1 we only support sharing images from the gallery app and via mailto: URIs triggered from the web browser.  This is consistent with column D in the FxOS v1 Specs Overview.
This should probably fall under browser support, not email.  Is that correct?
Adding benfrancis to the bug for feedback.
tracking-b2g18: --- → ?
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Where is the EMAIL-098 user story defined? Is there a bug for that? I don't see it in the 1.1 spreadsheet.

"initiate composing a message from other applications on the phone" is not specific to the browser app, I would interpret this to mean that any mailto: link in any web app should start composing a message in the email app. If this isn't already supported it would need to be a platform change to trigger a web activity when mailto: links are clicked.

The test case describes opening the browser app and "choose to share the page via Email" which is not what's described by the user story and not something I've seen UI designs for.

Can we get clarification on requirements here? Is this a new requirement or is the test case invalid?
on v1 status I see that (out-of-scoped!) WEBACT-001 in "Firefox OS v1 Application Status" says:

"A User can share a URL (pick Share) in a one way web activity (doesn't return back to previous app). For example, share a url, launch email with URL in it, send and go back to main email page."

It looks like the document I was referencing in comment 1 got deleted or my access was revoked or something equally frustrating involving our use of myriad spreadsheets for this tracking.  For permanence, the thing I am talking about right now can be found at:
on the "Feature Priority list" tab.

Also, this is probably an e-mail problem.  Although it could be fixed in either e-mail or the web browser, only e-mail can comprehensively cause sharing of URL's to work with e-mail.
From the comments so far it appears that this is not in spec for v1 and also if fixed, should be fixed in email.  If the v1 spec changes or product wants to make a case for getting this into v1 please renominate once it's fixed, landed & verified on trunk.
Duplicate of this bug: 895481
Note that we already do support the "share" activity, but only with a filter of "image/*", and in that case we extract attachments from the 'blobs' and 'filenames' part of the payload.

If all we do is just cram the URL in the body of the message, this is a really simply enhancement for us to implement.  If this wants to have a pre-populated subject or some body boilerplate, it's still simple for us, but harder for UX!

Needinfo'ing UX on this for feedback on whether they want a string or not or if there's already a spec somewhere I couldn't find it.
Flags: needinfo?(firefoxos-ux-bugzilla)
I am flagging Rob since email is in his area of Productivity, but I will note that there is a substantial list of email improvements for 1.2 (more so than for 1.1).
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(rmacdonald)
Adding needinfo on product per productwanted request.
Flags: needinfo?(ffos-product)
While this was originally a 1.0.1 requirement, it was moved out of scope.  As a result, I think it needs to be prioritized on the Browser backlog for a future release.  NI -> Karen/Chris.
Flags: needinfo?(krudnitski)
Flags: needinfo?(ffos-product)
Flags: needinfo?(clee)
My understanding here is that we are landing the framework / groundwork to allow shared intents to happen (bug 796565) but that the actual work to surface supported intents is based on that coding for those shared applications. 

Therefore to surface email as a shared intent requires code from the email team (using our framework for sharing that just got written)
Flags: needinfo?(krudnitski)
(In reply to Karen Rudnitski [:kar] from comment #11)
> Therefore to surface email as a shared intent requires code from the email
> team (using our framework for sharing that just got written)

I'll add it to the Productivity backlog then.
Flags: needinfo?(clee)
Assignee: nobody → gaye
Dependency on bug 802643 for a smooth user experience.
Depends on: 802643
Target Milestone: --- → 1.2 FC (16sep)
Any news on this?
Flags: needinfo?(gaye)
Blocks: 915270
Blocks a koi+ bug
blocking-b2g: --- → koi?
Attached file Pull request
NOTE: Please see to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:
Attachment #805418 - Flags: review?
Attachment #805418 - Flags: approval-gaia-v1.2?(doliver)
Flags: needinfo?(gaye)
Attachment #805418 - Attachment mime type: text/plain → text/html
Attachment #805418 - Flags: review? → review?(jrburke)
Comment on attachment 805418 [details]
Pull request

Looks good, final review nits discussed in IRC.
Attachment #805418 - Flags: review?(jrburke) → review+
c6b4cc05b2de6884a652c1c5ab8401216ffa46c1 landed on master
Closed: 8 years ago
Resolution: --- → FIXED
triage: blocking via comment #15
blocking-b2g: koi? → koi+
Uplifted c6b4cc05b2de6884a652c1c5ab8401216ffa46c1 to:
v1.2: f88e7d649a912fac98dcff0d7770bdb2a2b39f90
This broke mailto links, including those produced by the e-mail app's own linkification logic.

The bit that does this in the patch:
+      if (dataType === 'url') {
+        data.body = url;
+      } else { 

Is wrong because we (and presumably the browser?) use to open hyperlinks, including mailto URL's that we create.  popup_manager.js in the system app transforms the open call to an activity of the form: { name: 'view', data: { type: 'url', url: <theurl> } }

We should probably only be going into that 'copy the URL case verbatim' logic if the activity type is 'share'.

I'll file a separate bug for this and mark it "koi?".  Because of the complexity of the situation (impact on Browser app), the fact that this has been in the tree for a week and no one noticed, and the likely small size of the fix (well, apart from the tests), backout is probably not appropriate.
Verified on Buri 1.2 mozilla RIL.  Tapping the Share icon on the ribbon in the Browser will bring up a share page with email as an option.  Selecting the email option will launch Email with a link to the page in the body.

Build ID: 20130925004005
Gaia: b0e4a1333bb7bf0a749a384ba99e4f03f111e39a
Platform Version: 26.0a2
Comment on attachment 805418 [details]
Pull request

This one is koi+ so approval is implicit.
Attachment #805418 - Flags: approval-gaia-v1.2?(doliver) → approval-gaia-v1.2+
Flags: needinfo?(rmacdonald)
You need to log in before you can comment on or make changes to this bug.