New WebKitBrowserTest for content_shell not providing a prerenderer client.

New WebKitBrowserTest for content_shell not providing a prerenderer client.

The content_shell doesn't provide a prerendererclient (and chromium and DumpRenderTree do). This browsertest makes sure that encountering a prerendering element doesn't crash the content_shell.

This patch must land after https://bugs.webkit.org/show_bug.cgi?id=95036 lands and is gardened into Chromium.

R=jam@chromium.org
BUG=144556
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=153596

[gavinp, 2012-08-26 19:12:56]

jam, wdyt? This is the test side, see the link in the description for the WebKit
change to make content shell work.

[jochen (gone - plz use gerrit), 2012-08-26 19:37:45]

On 2012/08/26 19:12:56, gavinp wrote:
> jam, wdyt? This is the test side, see the link in the description for the
WebKit
> change to make content shell work.

I'm not a big fan of this test - eventually, content_shell will need to provide
a prerender client in order to run the layout tests..

[Avi (use Gerrit), 2012-08-26 20:55:58]

Why is pre-rendering in WebKit at all and in layout tests? :(

[gavinp, 2012-08-26 21:06:15]

On 2012/08/26 19:37:45, jochen wrote:
> On 2012/08/26 19:12:56, gavinp wrote:
> > jam, wdyt? This is the test side, see the link in the description for the
> WebKit
> > change to make content shell work.
> 
> I'm not a big fan of this test - eventually, content_shell will need to
provide
> a prerender client in order to run the layout tests..

That's true, and a good point. However, isn't the browser test framework robust
enough that this test could just turn off the client and the platform for
prerendering, and the test is still valid?

I think the answer here is to add a TODO(gavinp) comment, so that when we get
content_shell that advanced, the person who finds this test failing knows who to
bother?

[gavinp, 2012-08-26 21:21:27]

On 2012/08/26 20:55:58, Avi wrote:
> Why is pre-rendering in WebKit at all and in layout tests? :(

Short answer: because it has to be.

For layout tests, because we test code in WebKit using layout tests.

Longer answer:

Prerenders are not resource loads. The abort/error/load event model doesn't fit
them. When the link element controlling a prerender is removed from a document,
a signal must reach the prerender controller. When a page navigates away from a
page launching a prerender, a distinct signal must reach the controller. The old
API in which we had a make believe nonce resource load didn't support this
signalling.

See the reviews that added chrome/browser/prerender/prerender_link_manager.cc or
Source/WebCore/loader/Prerenderer.cpp to see more of this and the logic for it.
I'd love to hear more if you have any suggestions or questions!

[jam, 2012-08-27 17:09:02]

lgtm, thanks for the test

[commit-bot: I haz the power, 2012-08-27 19:43:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gavinp@chromium.org/10869068/6001

[gavinp, 2012-08-27 19:48:42]

On 2012/08/27 19:43:39, I haz the power (commit-bot) wrote:
> CQ is trying da patch. Follow status at
> https://chromium-status.appspot.com/cq/gavinp%40chromium.org/10869068/6001

The WebKit side of this landed as r126714, we gardened past that in r153470. The
current LKGR is r15349, so we are clear to land.

[commit-bot: I haz the power, 2012-08-27 20:11:28]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gavinp@chromium.org/10869068/6001

[commit-bot: I haz the power, 2012-08-28 00:44:33]

Change committed as 153596