Prerendering broken by latest Chrome stable release

[Don Schmitt]

Is it just me?  It appears that prerendering is completely broken in the Windows Stable Release Channel build that was released this morning ( 27.0.1453.93 m).  Has anyone else noticed this?

Everything is being rejected with "Unsupported Scheme".

[Matt Menke]

Thanks for contacting us.  How are you testing prerendering?

Using 27.0.1453.93 on Windows, I've tried prerenders from the omnibox, from Google searches, and from my own local files, and all seem to be working fine.  I've also successfully used prerendering with HTTPS pages.

[Don Schmitt]

Thanks for testing this out.  It appears the problem is with cross-domain <link rel> prerenders all begin rejected.  This is an issue for the StumbleUpon extension which uses prerenders to speed up stumbling.  And this no longer works because all of the prerenders are being rejected as "Unsupported Scheme".  Is there a security concern about cross-domain pre-renders that was mitigated in a recent release?  Here are the results (showing that they all "would have" been used):

Prerender History

Origin	URL	Final Status	Time
Link Rel Prerender (cross domain)	http://www.youngentrepreneur.com/blog/100-business-ideas-you-can-drive-home-today/	Unsupported Scheme	2013-05-21 20:16:56.965
Link Rel Prerender (cross domain)	http://cs-www.bu.edu/faculty/best/crs/cs101/F97/lectures/GreatIdeasInCS.html	WouldHaveBeenUsed	2013-05-21 20:16:53.965
Link Rel Prerender (cross domain)	http://cs-www.bu.edu/faculty/best/crs/cs101/F97/lectures/GreatIdeasInCS.html	Unsupported Scheme	2013-05-21 20:16:41.620
Link Rel Prerender (cross domain)	http://web.appstorm.net/roundups/51-web-apps-for-web-designers-and-developers/	WouldHaveBeenUsed	2013-05-21 20:16:39.005
Link Rel Prerender (cross domain)	http://web.appstorm.net/roundups/51-web-apps-for-web-designers-and-developers/	Unsupported Scheme	2013-05-21 20:16:34.763

[Matt Menke]

There's no new cross domain security issue I'm aware of.  One or two of my tests were cross domain, and seem to have worked fine.

Looking at my history, I now see one prerender that is also incorrectly reporting unsupported scheme, though it was https rather than http.

One possibility is that we could be noticing "chrome-extension://" requests, and then cancelling requests because of that.  I believe there were fixes in the logic for cancelling in the case of non-http/https subresources and redirects in M27.

I'll experiment with the StumbleUpon extension tomorrow and see if I can reproduce this.  Thanks again for the report - prerendering regressions, in particular, can very easily go unnoticed.

[Don Schmitt]

You are right, I jumped to the wrong conclusion about the root cause (a couple of times).

I just now tried some experimenting with typing URLs in the google search box and some were being rejected for Unsupported Scheme, but the exact same prerendered URL worked later.  I'm not sure yet what the pattern is, but it does seem to happen every time the StumbleUpon extension creates a prerender <link rel>.  I'll create a test page to see if I can reproduce this more easily.

[Matt Menke]

I've verified the cause of the issue and filed a bug (http://crbug.com/242959).  You can star it if you want to follow along.  Probably best to have future conversations there, so they're publicly available.

The reason it sometimes works for you is most likely that omnibox prerenders sometimes haven't fully loaded by the time you navigate to them, so they haven't yet tried to load your installed extensions.