You can clone with
You can repro this on myfavoritebeer
Steps to repro:
1. On Windows, install GCF http://www.google.com/chromeframe
2. In IE, force GCF to load myfavoritebeer.org; enter into the address bar: gcf:http://myfavoritebeer.org/
3. Click "Sign in"
EB: Sign-in dialog for Browserid
AB: Error page "Relay frame could not be found". This error page, notice, is rendered by IE, not by GCF.
I think the source of the problem is failure to communicate across iframe boundary. This is a known limitation of GCF.
I suspect the solution would be to use CORS headers to invoke the production.js script?
I think this approach might be useful for the GCF case. It uses an <object> tag to simulate an iframe. http://src.chromium.org/svn/branches/472/src/chrome_frame/test/data/postmessage_basic_host.html
Hullo indeed. This has gone stale. Adding a couple more stars since it came up in the dev-identity email list this week.
@jbonacci - I'm not sure this is really a 4*, but I agree that we should investigate the problem and what possible solutions exist. What percentage of the market is using GCF? Is it substantial enough to consider it an A-Grade browser? Is GCF more popular than other unsupported browsers like Dolphin? Is it worth putting GCF over other features/issues or is it a "nice to have"?
When you're investigating usage statistics, keep in mind that there's a metric you need to consider with GCF that doesn't apply to Dolphin and other browsers: how many web sites offer a GCF header or meta tag? People don't install GCF out of thin air and browse the web with it. They encounter web sites that suggest or require that they install it.
In our case we require IE users install GCF because it's a WebGL site. We cannot use BrowserID because of that.
Put another way, any web site that exposes WebGl has to choose between supporting BrowserID and IE.
Is this not simply a case of the originating page (myfavoritebeer.org) being from GCF, but the dialog rendering with plain IE (since it's a new window, without the gcf: prefix), and so they can't communicate?
Sean, yes. Here's a reference: http://www.chromium.org/developers/how-tos/chrome-frame-getting-started/differences-between-chrome-and-chrome-frame#TOC-Popup-windows-and-window.opener
So, I've confirmed that I can talk to popups using the method from the link above.
@lloyd To fix this would require a patch to WinChan. It would need to check for GCF, and if so, use a relay iframe (different than normal IE) that would open the popup, and then the iframe becomes the mediator. So, RP -> iframe -> dialog, and then dialog -> iframe -> RP. I've got a half working implementation, and can flesh it out if it's worth it to contain this much complexity.
Of course, IE doesn't work using this method, so both kinds of relaying would need to exist.
if I didn't make it clear, the difference is that for GCF the iframe needs to open the window itself , and the popup doesn't need to search for the relay; the popup just posts messages, oblivious to the cruel world it is in.
My 2 cents: I would argue that supporting chrome frame is worth the added complexity.
Since Google is retiring Google Chrome Frame [http://blog.chromium.org/2013/06/retiring-chrome-frame.html], I do not believe it makes sense to add support for it. I am all for a non-popup flow, but adding support for GCF should not be a goal. @seanmonstar?
I'm fine with GCF being an explicit non-goal.
Sounds good to me.