+++ This bug was initially created as a clone of Bug #424932 +++ DEFECT DESCRIPTION: [HereMaps]Send email failed when the place share via email REPRODUCING PROCEDURES: 1.Find a place and share via email; 2.The interface skip to email compose interface; 3.Add a email address and send,it pop up "Sending email failed";->K.O(see logs) PS: From email interface write an email send is OK. And the network also OK. EXPECTED BEHAVIOUR: The place share via email should send successfully and can be received. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: 5/5 For FT PR, Please list reference mobile's behavior: AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.037 Firefox os v1.0.1 Mozilla build ID: 20130310070203. ++++++++++ end of initial bug #424932 description ++++++++++ CONTACT INFO (Name,Phone number): DEFECT DESCRIPTION: REPRODUCING PROCEDURES: EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:

The way I read this bug is that the HERE Maps app allows a user to share via email, which fires a web activity over to the email app with the info. User provides the valid information to send the email and it fails to send.

I am not sure Maps is really using a web activity. We try to us 'mailto:' wherever we can.

To confirm what Andy wrote, we are indeed using a "mailto:" link for this. Here is an example of a URL we create: mailto:?subject=More&body=Hey%2C%20here's%20something%20for%20you%20to%20check%20out%20on%20HERE.%3A%20http%3A%2F%2Fher.is%2FVGbqT%0A%0AMore%0AMotzstra%C3%9Fe%2028%0A10777%20Berlin%0AGermany We open the link using window.location.href: window.location.href = "mailto:?subject=" + encodeURIComponent(subject) + "&body=" + encodeURIComponent(message); This then opens the Mail application which fails to send the email. Is this usage of mailto correct?

That looks fine to me. asuth could tell us what the email app supports.

From the bug description, it sounds like the mailto URI parsing is working acceptably, but the problem is in sending. Comment 0 mentions logs, but none are provided. We need logs of a failed run; please see https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo A screenshot of the compose window for a message that failed to send would also be useful just in case there is a bug in mailto parsing. Can I set needinfo? on the not-a-real-email reporter address? We'll see...

Created an attachment (id=377924) logs

(In reply to sync-1 from comment #7) > Created an attachment (id=377924) > logs No log was created on bugzilla.mozilla.org; it seems like there is a deficiency in whatever bugzilla synchronization tool is being used. Please provide the attachment on bugzilla.mozilla.org directly unless the synchronization tool that is being used can be fixed.

Hi,I want to know how could you fix this?

(In reply to sync-1 from comment #10) > Hi,I want to know how could you fix this? Still not sure what the problem is. I just had a look at the logs, and I don't understand what they are. The request on comment 6 was for textual "adb logcat" output. The attachment is a .rar file of a binary 36M "share.isf" file, which is a format unfamiliar to me. If someone could explain to me what type of file it is and how I go about using it as a logcat log, or better yet, could just provide a logcat log, that would be very helpful.

(In reply to comment #11) > Comment from Mozilla:(In reply to sync-1 from comment #10) > > Hi,I want to know how could you fix this? > > Still not sure what the problem is. > > I just had a look at the logs, and I don't understand what they are. The > request on comment 6 was for textual "adb logcat" output. The attachment is a > .rar file of a binary 36M "share.isf" file, which is a format unfamiliar to me. > > If someone could explain to me what type of file it is and how I go about using > it as a logcat log, or better yet, could just provide a logcat log, that would > be very helpful. > when I search some place ,for example shanghai ,then I want to share this information via email,after send successful which dispalying on send UI,but other side do not recieve this mail.This is also ocurring via sms.

Issue with not received sms is already handled in bug 853311.

OK,I see.Thank you.

no new information.

Looks like a small graphical artifact/object in "To" field causes this issue (see attached file "Screenshot_when_opened_from_HERE_Maps.png"). After removing it (just tap "To" field and tap backspace/delete key), you can provide an email address and email is sent successfully. This weird object is also there, when using the attached simple app, so it has nothing to do with HERE Maps.

HI, how about this bug?

Triage - leo+ as functionally broken. Andrew, can you check this out? attached image in comment 17 shows this object in the to field, which seems to break the sending.

Correctly parse mailto links that lack a 'to' address and add unit tests. Also update 'addressesToArray' function to correctly return an empty array if no argument is provided, instead of an array containing the empty string.

Comment on attachment 772993 [details] Pull Request #10875 - Properly parse mailto links Awesome! Thanks! r=asuth

Thanks Andrew! Landed on master: https://github.com/mozilla-b2g/gaia/commit/4be813b65ea30e3914ce732d1401385d8fb78b68

I was not able to uplift this bug to v1-train. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1-train git cherry-pick -x -m1 4be813b65ea30e3914ce732d1401385d8fb78b68 <RESOLVE MERGE CONFLICTS> git commit

This fix depends on the patch for bug 886446 which refactors some of the email code and adds the apps/email/js/query_uri.js file which has the fix for this bug. We can either have the patch for 886446 uplifted first or I can submit another PR for v1-train with the fix in apps/email/js/mail_app.js where the code from 'query_uri.js' from master resides (https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/email/js/mail-app.js#L208). Andrew, any thoughts on this?

(In reply to Mihai Cirlanaru [:mihai][:mcirlanaru] from comment #27) > This fix depends on the patch for bug 886446 which refactors some of the > email code and adds the apps/email/js/query_uri.js file which has the fix > for this bug. > > We can either have the patch for 886446 uplifted first or I can submit > another PR for v1-train with the fix in apps/email/js/mail_app.js where the > code from 'query_uri.js' from master resides > (https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/email/js/mail-app. > js#L208). > > Andrew, any thoughts on this? We want to uplift bug 886446, but there are still a few follow-ups that need to be fixed and landed (relating to delays before the app responds to clicks) before we can consider uplift. Given that we can't guarantee that refactoring will get uplifted and it could take a week or more if it does get uplifted, probably the best thing to do is to formulate a v1-train compatible patch and just land that now so we don't forget about this. Since the patch will be substantially the same, my r=asuth still holds; feel free to land the fix once you make it.

v1-train compatible patch with pull request: https://github.com/mozilla-b2g/gaia/pull/10953 Merged to v1-train: https://github.com/mozilla-b2g/gaia/commit/2e711c1fdd2441bda34703cd7d8d3c0f1cc2c396

v1.1.0hd: 2e711c1fdd2441bda34703cd7d8d3c0f1cc2c396 v1.1.0hd: be5ca81257e9c7638eda7460c80adfab13c34b8d