As a user, I want the ability to launch the Email application from an email address on a webpage, with the recipient precomposed so that I don't need to remember the email address to manually enter it into the Email application. Acceptance Criteria: 1. Interacting with an email address on a webpage (that does not use the mailto tag) invokes the Email app with that email address prepopulated in the To: field. 2. Interaction and visuals match UX spec.
UCID: Browser-115 User Story: As a user, I want the ability to launch the Email application from an email address on a webpage, with the recipeint precomposed so that I don't need to remember the email address to manually enter it into the Email application.
This is already working in 1.0.0 for mailto links. We do not try to parse the content to detect other email addresses. We need more detail on this user story to judge effort/feasibility.
This story is referring to providing email invocation for recognized email addresses, beyond mailto links. This would improve usability in directly emailing for the plethora of cases where mailto links are not used on a webpage.
I would think that automatically detecting email addresses in web content, making them clickable and making that click trigger a web activity would have to be entirely implemented on the platform side. The browser app has no access to the content of a web page with the current design of the API. Should this (and the dialer equivalent) apply to only web content inside the browser app, or any app?
We should be careful with that I believe. I understand how it can be helpful in some situations but it can be very quickly invasive. The email written in plain text would have to be styled somehow to make it clear it is actionable. That could break the page layout/design and annoy the user. I think we should probably focus on a good copy/paste feature instead.
I agree with Mounir. Also, when we did something similar in Fennec to create tel: uris this was such a performance hit that we removed it. And we were not even trying to deal with dynamically created content in pages.
The way fennec did this is not the way I would have chosen to do it :). We should be able to do this plenty efficiently within gecko itself.
And leverage that for "linkifying" phone numbers and URLs as well.
Are we talking about a load page listener type of solution here, or something else?
Clearing tracking-b2g18 flag from User Story bugs. This flag is for bugs that we would take fixes for in the 1.x branch. Feature work should be officially slotted into a release instead with leo+. If this story is intended for v1.1, please nominate for leo? blocking.