New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: Fixed
Closed: Jul 2015
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Blocked on:
issue 485066

Sign in to add a comment

Issue 461329: ERR_UNKNOWN_URL_SCHEME for 'mailto:' in packaged app

Reported by, Feb 24 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36

Steps to reproduce the problem:
I have attached a reduced test-case:

1. packaged app runs `‘webview.html’)`
2. webview.html contains a webview element `<webview id="econ-webview" partition="persist:economist-storage"></webview>`
3. the webview is navigated to a test page at which contains a button
4. when the button is clicked, the mailto protocol is invoked with `parent.location = "mailto:?subject=test%20email”;`

What is the expected behavior?
The 'mailto:' URL should invoke the default email client.

What went wrong?
In the affected browsers, this error is encountered:

The web page at mailto:?subject=test%20email might be temporarily down or it may have moved permanently to a new web address.

WebStore page:

Did this work before? N/A 

Chrome version: 40.0.2214.115  Channel: stable
OS Version: OS X 10.10.2
Flash Version: Shockwave Flash 16.0 r0

The reduced test case fails on OS X and Windows, but seems to work fine on Chrome OS.

I believe at some stage that this was a problem on CrOS, which appears to have been fixed.

NB. this ticket has also been raised with CWS Developer Support (thread "Re: [3-9855000005947] Economist App: Email sharing button does not work on Chrome OS, works on Windows").
Economist app -
2.2 KB Download
329 bytes View Download

Comment 1 by, Feb 24 2015

Screenshot of the error page.
screenshot 2015-02-24 12.43.33.png
26.8 KB View Download

Comment 2 Deleted

Comment 3 by, Feb 24 2015

Comment 4 by, Feb 24 2015

Status: Untriaged
Fady, could you triage this? Is it really a bug, or should the navigation be intercepted and suppressed by the emebedder in this case?

Comment 5 by, Feb 24 2015

Labels: Cr-Platform-Apps-BrowserTag

Comment 6 by, Feb 24 2015

The embedder is not notified, so it cannot be intercepted. Also, in a weird twist, I've found that if I first open some other URL (via the embedder doing the mailto actually starts working.

Comment 7 by, Feb 25 2015

I've found a work-around. The embedder actually is notified, but it's in a "loadabort" event.
          wv.addEventListener('loadabort', function(e) {
              if (e.url.match(/^mailto:/)) {
Where wv is the webview and cw is the content window of my hosting page which has a function that just calls on the passed URL.

Comment 8 by, Mar 2 2015

Thanks, this does indeed work. Since my embedded JS app in the webview is aware of the version of the Chrome wrapper it's running inside, I've decided to simplify this and just message up from the app to the content window when a mailto protocol is required, rather than ever attempting from inside the webview.

I did notice that, in Chrome/OS X at least, whilst the mail client correctly opens with a new email, there is also a blank browser tab left open with the mailto: URL. Can this be avoided?

Comment 9 by, Mar 2 2015

The chrome app hands off the mailto: URL to the O/S to open in the default browser. What the browser does is obviously out of our control. Safari doesn't leave a blank tab, for example.

Comment 10 by, Mar 3 2015

That's fine, understood.

To confirm: are you still treating the webview behaviour as a bug? If not, then it'd be great to mention your workaround somewhere in the documentation, as it's certainly unexpected that simple mailto: links don't work from within the webview.

Many thanks for your help.

Comment 11 by, Mar 3 2015

(I'm not on the chromium project, I'm just a simple user like yourself)

Clearly the mailto behavior is a bug. In fact, if the app does a (and the host intercepts that and does the magic to deal with it), mailto URLs actually start working the normal way.

Comment 12 by, Mar 3 2015

Bad news: Chrome 41 just dropped, and my workarounds aren't working right any more. Will update when I find a solution that is robust in the 41.

Comment 13 by Deleted ...@, Mar 26 2015

I'm at the same issue. Have you found any workaround solution yet?

Comment 14 by, Mar 26 2015

This is working:

1. Include function like this in the main html page of your packaged app:

function doOpen(u) {;}

2. This is in my JS that creates the window:

      var cw = createdWindow.contentWindow;
      cw.addEventListener("load", function() {
          iframe = cw.document.getElementsByTagName("webview")[0];
          // If the webview asks for a window, throw it to a browser
          iframe.addEventListener('newwindow', function(e) {
          // If the load fails with the UNKNOWN_URL_SCHEME bug, throw it to a browser.
          iframe.addEventListener('loadabort', function(e) {
              if (e.url.match(/^mailto:/) && e.reason=="ERR_UNKNOWN_URL_SCHEME") {
          iframe.addEventListener('loadstart', function(e) {
              // Sometimes there is an about:blank, just ignore those
              if (e.url.match(/^about:/)) { return ; }
              // After the UNKNOWN_URL_SCHEME bug, there will be a dead page
              // In that case, reload the whole app
              if (e.url.match(/^data:/)) { iframe.executeScript({ code: "document.getElementsByTagName('iframe')[0].src = 'index.html'" }); return }
              // If we navigate to a mailto:, just back up and undo that
              if (e.url.match(/^mailto:/)) { iframe.back(); return ; }

This is not a perfect workaround, since if the app exhibits the bug, you'll end up with a page reload happening. The bug only happens if you've never opened a window from the code running in the webview. That open of about:blank I did in the error handler was an attempt to get the app into that state, but it didn't work. However, since everything was actually working pretty well, I just left it there, since it didn't seem to cause any harm.

Comment 15 by, Mar 26 2015

BTW, another "workaround" you might consider is to not use a Chrome packaged app at all, and instead use a hosted app in Firefox with a cache manifest. We are finding that firefox is considerably less buggy than chrome when it comes to desktop apps. And they also install the app in a much more standard way that users understand. You don't have to use that silly launcher thing. It's just a program like any other program. Also, you can self-host the apps, so there's no annoying store to deal with. And it works in China.

Comment 16 by Deleted ...@, Apr 1 2015

Thank you very much! It's working with your solution!

Comment 17 by, Apr 7 2015

Status: Assigned
Reassigning to Paul Meyer.

Comment 18 by, Apr 14 2015

Labels: -Pri-2 Pri-1

Comment 19 by, Apr 22 2015

Status: Started

Comment 20 by, May 5 2015

The repro steps now result in "ERR_FAILED" rather than "ERR_UNKNOWN_URL_SCHEME", but the bug is still the same otherwise.

Comment 21 by, May 6 2015

Blockedon: chromium:485066

Comment 23 by, Jul 22 2015

Status: Fixed

Sign in to add a comment