Closed Bug 1024856 Opened 10 years ago Closed 10 years ago

[email/UI] Change hyperlink handling to explicitly trigger "view" activity for http/http/rtsp and internally handle mailto by pushing a 'compose' card


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

Not set


(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)

2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed


(Reporter: asuth, Assigned: jrburke)




(1 file)

Excerpt from where the bug got morphed into a window manager bug:
I ended up talking to people about this more.  The take-away was that the email app should switch to explicitly triggering a 'view' web activity for http/https(/rtsp) links.

And for mailto links we should probably just use our own internal mechanisms since it's arguably silly for us to trigger an activity in that case.  (Certainly we're much more likely to run afoul of weird/crazy window manager bugs.  It might become less silly when we go haida.)

Unfortunately, I don't think we can get rid of the mailto confirmation prompt unless we overhaul our handling of bubbles in the compose UI.  I can formulate a mailto link that shows a display name of "" but really sends the message to "" and the user would have to click on the bubble to see the actual email address.

At some point we used to subtly differentiate display names from email addresses via use of italics.  That has clearly gone away.

The best compose mitigation would probably be to put the compose UI into a special bubble display mode that results in the bubble displaying both the display name and the e-mail address.  While there will always be an ambiguity problem, I think displaying just enough that it becomes clear that something hinky is going on is sufficient. (ex: is foo@bar the e-mail address or is bar@baz the email address when I see: "foo@bar: bar@baz"?)  This would be far superior than us showing the mailto encoded URI which has the potential to be very opaque/confusing to the user (things can get %NN encoded, etc.) but with the upside that a user seems more likely to say yes to a mailto URI that looks like random gibberish.  (Or a heuristic I'm using a lot is whether an expert such as myself has a hope of realizing they're being phished; if I don't have a chance, then the user is probably not going to either.)

And from
Er, and some of the interesting rationale for using activities was that even with _blank for webpages opens things in our cookie jar.  And that is because _blank intentionally opens another window in our process space so that when our app dies/gets killed the window we opened dies with us.

Note that bug 1009271 is currently a 2.0 blocker since there is a regression.  This could likely also be handled as a regression and 2.0 blocker, but for string reasons we would want to maintain the currently dialog in its entirety and implement any changes to the prompting mechanism as a follow-up bug.
Attached file GitHub pull request
For links in an email, prompt as usual, but if the link starts with 'mailto:' fast path to a compose card. Otherwise, use a 'view' MozActivity.

In the process of consolidating mailto parsing, query_uri was modified to return an object with named properties instead of the more unintuitive array form. query_uri.js was also updated to pass jshint, and its unit test was updated.

Did this simpler adjustment instead of the larger suggestions around mailto links in the bug ticket so that this can easily uplift to 2.0, since there are no string changes.
Assignee: nobody → jrburke
Attachment #8450657 - Flags: review?(bugmail)
Asking for 2.0? since it will help bug 1009271.
blocking-b2g: --- → 2.0?
Target Milestone: --- → 2.0 S6 (18july)
blocking-b2g: 2.0? → 2.0+
Comment on attachment 8450657 [details] [review]
GitHub pull request

Great cleanup!

And I agree that changing the mailto prompt process/etc. is out of scope for this bug (even ignoring the fact that it might need a new string, etc.)
Attachment #8450657 - Flags: review?(bugmail) → review+
Merged to master:

from pull request:
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.