Add Start/Stop event signalling on Prerenders.

Add Start/Stop event signalling on Prerenders.

We've switched to our new event names, we've made sure that the PrerenderHandle and the PrerenderLinkManager are connected, and now, we pass these events into WebKit.

This change depends on the WebKit changes in https://bugs.webkit.org/show_bug.cgi?id=96474 landing first. As well, this CL depends on the earlier work in https://chromiumcodereview.appspot.com/11316311/ , which makes the PrerenderHandle an observer of the PrerenderContents, being landed first. As well, since this code depends on WebPrerender.h changing, it actually needs to be staged carefully between WebKit & Chrome. Careful readers will also observe that this change obsoletes https://chromiumcodereview.appspot.com/10918189/ .

R=mmenke@chromium.org
BUG=None

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=173625

[gavinp, 2012-12-05 20:07:19]

Matt, WDYT?

A note on staging: this CL can't land as it is (peek at the try patch to see the
WebKit changes that go concurrently with it). But please review this as you
would any other commit.

If you approve of these changes, the staging plan is probably:

1. Land a commit in WebKit adding deprecatedAdd(), deprecatedCancel() and
deprecatedAbandon(), which follow the same interface as the current
add/cancel/abandon.

2. After (1) gardens into Chrome, change prerender_dispatcher.(h|cc) to use the
"new" deprecated interfaces.

3. Land the new interface into WebKit with the new add/cancel/abandon which pass
a WebPrerender* instead of const WebPrerender&.

4. After (3) gardens into Chrome, Land this change (I'll have to make another
upload rebasing these changes on top of the commit from (2)).

5. Land a commit in WebKit removing all the deprecated interfaces.

[gavinp, 2012-12-06 15:01:56]

Actually, hold off on reviewing this (there's two other upstream reviews
anyway), I'm reworking this code to work better with WebKit. And simplify
staging!

[gavinp, 2012-12-06 18:50:44]

Good news: I reworked the WebKit side of this such that there is no complex
staging required. This change is dependent on WebKit Bug 96474 landing, but
that's it.

[mmenke, 2012-12-07 17:11:48]

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
File chrome/browser/prerender/prerender_browsertest.cc (right):

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:2284:
IN_PROC_BROWSER_TEST_F(PrerenderBrowserTest, PrerenderEvents) {
Suggest a test where the page itself cancels the prerender, and we make sure
stopped is set, or not, depending on the other CL.

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:2308:
&received_prerender_started));
Is there a reason for this?  I don't object to it, just wondering if there's
some motivation I'm missing.

https://codereview.chromium.org/11459003/diff/15001/chrome/renderer/prerender...
File chrome/renderer/prerender/prerender_dispatcher.cc (right):

https://codereview.chromium.org/11459003/diff/15001/chrome/renderer/prerender...
chrome/renderer/prerender/prerender_dispatcher.cc:108: prerender));
It looks like we currently eternally accumulate prerenders here if they aren't
started in the browser, even if webkit cancels/abandons them.  Am I missing
something?

[mmenke, 2012-12-07 19:12:46]

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
File chrome/browser/prerender/prerender_browsertest.cc (right):

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:2284:
IN_PROC_BROWSER_TEST_F(PrerenderBrowserTest, PrerenderEvents) {
On 2012/12/07 17:11:48, Matt Menke wrote:
> Suggest a test where the page itself cancels the prerender, and we make sure
> stopped is set, or not, depending on the other CL.

That test could actually just be added to the corresponding RemovingLink test.

In fact, I think that we should add event testing to all the other RemovingLink
tests, if we can reasonably manage to do so.  I'm not sure that we can
reasonably make a test for the
"PrerenderPageRemovingLinkWithTwoLinksRemovingOne" test (Though I've love to
have a test if we can manage it in a way that is results in non-flaky failures
on regression).

I'd also suggest some others:
* Make sure the events work for a prerender that starts life pending prerender,
which we end up starting and then cancelling (Due to visiting the source
prerender).
* Cancel a pending prerender while it's still pending, and make sure we never
start the prerender or create a prerender contents.  Should also make sure we
never send the send event for the prerender.

I think these make the most sense as browser_tests, to make sure everything
hooked in all the way through, and shouldn't be too hard to manage, but if you
feel some make more sense as unit tests, that's fine.

[gavinp, 2012-12-14 21:48:52]

Remediation, and the tests you asked for.

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
File chrome/browser/prerender/prerender_browsertest.cc (right):

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:2284:
IN_PROC_BROWSER_TEST_F(PrerenderBrowserTest, PrerenderEvents) {
On 2012/12/07 19:12:47, Matt Menke wrote:
> On 2012/12/07 17:11:48, Matt Menke wrote:
> > Suggest a test where the page itself cancels the prerender, and we make sure
> > stopped is set, or not, depending on the other CL.
> 
> That test could actually just be added to the corresponding RemovingLink test.
> 
> In fact, I think that we should add event testing to all the other
RemovingLink
> tests, if we can reasonably manage to do so.  I'm not sure that we can
> reasonably make a test for the
> "PrerenderPageRemovingLinkWithTwoLinksRemovingOne" test (Though I've love to
> have a test if we can manage it in a way that is results in non-flaky failures
> on regression).
> 
> I'd also suggest some others:
> * Make sure the events work for a prerender that starts life pending
prerender,
> which we end up starting and then cancelling (Due to visiting the source
> prerender).
> * Cancel a pending prerender while it's still pending, and make sure we never
> start the prerender or create a prerender contents.  Should also make sure we
> never send the send event for the prerender.
> 
> I think these make the most sense as browser_tests, to make sure everything
> hooked in all the way through, and shouldn't be too hard to manage, but if you
> feel some make more sense as unit tests, that's fine.

Done.

https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:2308:
&received_prerender_started));
On 2012/12/07 17:11:48, Matt Menke wrote:
> Is there a reason for this?  I don't object to it, just wondering if there's
> some motivation I'm missing.

Nope, none. I think some of these ASSERTs should be EXPECTS though.

https://codereview.chromium.org/11459003/diff/15001/chrome/renderer/prerender...
File chrome/renderer/prerender/prerender_dispatcher.cc (right):

https://codereview.chromium.org/11459003/diff/15001/chrome/renderer/prerender...
chrome/renderer/prerender/prerender_dispatcher.cc:108: prerender));
On 2012/12/07 17:11:48, Matt Menke wrote:
> It looks like we currently eternally accumulate prerenders here if they aren't
> started in the browser, even if webkit cancels/abandons them.  Am I missing
> something?

No, nothing. But the new uploads should clean that up some.

[mmenke, 2012-12-14 21:52:41]

On 2012/12/14 21:48:52, gavinp wrote:
> Remediation, and the tests you asked for.
> 
>
https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
> File chrome/browser/prerender/prerender_browsertest.cc (right):
> 
>
https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
> chrome/browser/prerender/prerender_browsertest.cc:2284:
> IN_PROC_BROWSER_TEST_F(PrerenderBrowserTest, PrerenderEvents) {
> On 2012/12/07 19:12:47, Matt Menke wrote:
> > On 2012/12/07 17:11:48, Matt Menke wrote:
> > > Suggest a test where the page itself cancels the prerender, and we make
sure
> > > stopped is set, or not, depending on the other CL.
> > 
> > That test could actually just be added to the corresponding RemovingLink
test.
> > 
> > In fact, I think that we should add event testing to all the other
> RemovingLink
> > tests, if we can reasonably manage to do so.  I'm not sure that we can
> > reasonably make a test for the
> > "PrerenderPageRemovingLinkWithTwoLinksRemovingOne" test (Though I've love to
> > have a test if we can manage it in a way that is results in non-flaky
failures
> > on regression).
> > 
> > I'd also suggest some others:
> > * Make sure the events work for a prerender that starts life pending
> prerender,
> > which we end up starting and then cancelling (Due to visiting the source
> > prerender).
> > * Cancel a pending prerender while it's still pending, and make sure we
never
> > start the prerender or create a prerender contents.  Should also make sure
we
> > never send the send event for the prerender.
> > 
> > I think these make the most sense as browser_tests, to make sure everything
> > hooked in all the way through, and shouldn't be too hard to manage, but if
you
> > feel some make more sense as unit tests, that's fine.
> 
> Done.
> 
>
https://codereview.chromium.org/11459003/diff/15001/chrome/browser/prerender/...
> chrome/browser/prerender/prerender_browsertest.cc:2308:
> &received_prerender_started));
> On 2012/12/07 17:11:48, Matt Menke wrote:
> > Is there a reason for this?  I don't object to it, just wondering if there's
> > some motivation I'm missing.
> 
> Nope, none. I think some of these ASSERTs should be EXPECTS though.
> 
>
https://codereview.chromium.org/11459003/diff/15001/chrome/renderer/prerender...
> File chrome/renderer/prerender/prerender_dispatcher.cc (right):
> 
>
https://codereview.chromium.org/11459003/diff/15001/chrome/renderer/prerender...
> chrome/renderer/prerender/prerender_dispatcher.cc:108: prerender));
> On 2012/12/07 17:11:48, Matt Menke wrote:
> > It looks like we currently eternally accumulate prerenders here if they
aren't
> > started in the browser, even if webkit cancels/abandons them.  Am I missing
> > something?
> 
> No, nothing. But the new uploads should clean that up some.

I don't expect reviewing this to be too difficult / time consuming, since I've
already seen the browser tests, but probably best not to do what I expect to be
the final signoff review at 5:00 on a Friday.  I'll plan to get back to you over
the weekend.

[mmenke, 2012-12-17 17:08:18]

Tests look good and complete to me...  Well..reason they're not racy is ugly,
but that's to be expected.

https://codereview.chromium.org/11459003/diff/50001/chrome/browser/prerender/...
File chrome/browser/prerender/prerender_browsertest.cc (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:1234:
EXPECT_TRUE(IsEmptyPrerenderLinkManager());
Forgot how ugly this was.  Think it's worth noting that this is non-racy because
thethe event to remove the element from the renderer does the exact same
thread/process hops as the blocking Javascript calls.

https://codereview.chromium.org/11459003/diff/50001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:1252: 
nit:  Weird space for space.

https://codereview.chromium.org/11459003/diff/50001/chrome/renderer/prerender...
File chrome/renderer/prerender/prerender_dispatcher.cc (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/renderer/prerender...
chrome/renderer/prerender/prerender_dispatcher.cc:47: std::multimap<GURL,
int>::value_type(prerender.url(), prerender_id));
nit:  Suggest using OnPrerenderAddAlias here.  Makes it more like the unit test,
and I generally think that adding/removing STL container elements in fewer
places tends to make code less regression prone.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader.html:7: var
receivedPrerenderStopEvents = Array();
Google Javascript style guide prefers array / object literals over the
constructors.

This applies to all files.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader_removing_links.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:15: var
linksToRemove = ExtractGetParameterBadlyAndInsecurely('links_to_remove', 1);
nit:  While you're here, could you rename these "numLinksToRemove" /
"numLinkToInsert"?  AS it is, have to read the code to figure out they're
counts, and not URLs.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:28: function
RemoveLinkElements() {
optional:  I think the C++ part of your unit tests would be more legible if you
renamed this to "RemoveLinkElement(var index)", and remove linksToRemove.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:34: 
nit:  While I don't really have any preference about whether we have spaces
before / after script tags or not, it looks like this is the only case we have
one, just before the clsoe tag at least in this CL.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:40: for (var i =
1; i <= linksToInsert; ++i) {
Is there a reason you go from 1 to linksToInsert, rather than 0 to linksToInsert
- 1?

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:48:
MakePrerenderStopHandlerForLink(i), false);
optional:  Maybe I just have a bias against funtions that return functions, and
how Javascript handles scoping, but I think this would be a little cleaner as:

PrerenderStopHandleForLink.bind(null, i);

With PrerenderStopHandleForLink being the inner function in
MakePrerenderStopHandleForLink.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_page_pending.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_page_pending.html:4: while pending never
start.
nit "a pending prerenders which are" -> "pending prerenders which are" or "a
pending prerender which is"

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_page_pending.html:4: while pending never
start.
This comment is incorrect.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_page_removes_pending.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_page_removes_pending.html:4: while pending
never start.
nit "a pending prerenders which are" -> "pending prerenders which are" or "a
pending prerender which is"

[mmenke, 2012-12-17 17:08:58]

Oh, and contrary to what I said, I'll have time to sign off on this - was
thinking more along the lines of not having time to review significant changes.

[gavinp, 2012-12-17 20:34:02]

https://codereview.chromium.org/11459003/diff/50001/chrome/browser/prerender/...
File chrome/browser/prerender/prerender_browsertest.cc (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:1234:
EXPECT_TRUE(IsEmptyPrerenderLinkManager());
On 2012/12/17 17:08:18, Matt Menke wrote:
> Forgot how ugly this was.  Think it's worth noting that this is non-racy
because
> thethe event to remove the element from the renderer does the exact same
> thread/process hops as the blocking Javascript calls.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/browser/prerender/...
chrome/browser/prerender/prerender_browsertest.cc:1252: 
On 2012/12/17 17:08:18, Matt Menke wrote:
> nit:  Weird space for space.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/renderer/prerender...
File chrome/renderer/prerender/prerender_dispatcher.cc (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/renderer/prerender...
chrome/renderer/prerender/prerender_dispatcher.cc:47: std::multimap<GURL,
int>::value_type(prerender.url(), prerender_id));
On 2012/12/17 17:08:18, Matt Menke wrote:
> nit:  Suggest using OnPrerenderAddAlias here.  Makes it more like the unit
test,
> and I generally think that adding/removing STL container elements in fewer
> places tends to make code less regression prone.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader.html:7: var
receivedPrerenderStopEvents = Array();
On 2012/12/17 17:08:18, Matt Menke wrote:
> Google Javascript style guide prefers array / object literals over the
> constructors.
> 
> This applies to all files.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader_removing_links.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:15: var
linksToRemove = ExtractGetParameterBadlyAndInsecurely('links_to_remove', 1);
On 2012/12/17 17:08:18, Matt Menke wrote:
> nit:  While you're here, could you rename these "numLinksToRemove" /
> "numLinkToInsert"?  AS it is, have to read the code to figure out they're
> counts, and not URLs.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:28: function
RemoveLinkElements() {
On 2012/12/17 17:08:18, Matt Menke wrote:
> optional:  I think the C++ part of your unit tests would be more legible if
you
> renamed this to "RemoveLinkElement(var index)", and remove linksToRemove.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:34: 
On 2012/12/17 17:08:18, Matt Menke wrote:
> nit:  While I don't really have any preference about whether we have spaces
> before / after script tags or not, it looks like this is the only case we have
> one, just before the clsoe tag at least in this CL.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:40: for (var i =
1; i <= linksToInsert; ++i) {
On 2012/12/17 17:08:18, Matt Menke wrote:
> Is there a reason you go from 1 to linksToInsert, rather than 0 to
linksToInsert
> - 1?

Likely I was channeling PASCAL. Fixed.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:48:
MakePrerenderStopHandlerForLink(i), false);
On 2012/12/17 17:08:18, Matt Menke wrote:
> optional:  Maybe I just have a bias against funtions that return functions,
and
> how Javascript handles scoping, but I think this would be a little cleaner as:
> 
> PrerenderStopHandleForLink.bind(null, i);
> 
> With PrerenderStopHandleForLink being the inner function in
> MakePrerenderStopHandleForLink.

You may have such a bias; it's also plausible that I am unduly comfortable with
lexical scope and closures.

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_page_pending.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_page_pending.html:4: while pending never
start.
On 2012/12/17 17:08:18, Matt Menke wrote:
> nit "a pending prerenders which are" -> "pending prerenders which are" or "a
> pending prerender which is"

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_page_pending.html:4: while pending never
start.
On 2012/12/17 17:08:18, Matt Menke wrote:
> nit "a pending prerenders which are" -> "pending prerenders which are" or "a
> pending prerender which is"

Done.

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_page_removes_pending.html (right):

https://codereview.chromium.org/11459003/diff/50001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_page_removes_pending.html:4: while pending
never start.
On 2012/12/17 17:08:18, Matt Menke wrote:
> nit "a pending prerenders which are" -> "pending prerenders which are" or "a
> pending prerender which is"

Done.

[mmenke, 2012-12-17 20:47:53]

LGTM, modulo comments.

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader.html (right):

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader.html:10:
receivedPrerenderStartEvents[1] = true;
receivedPrerenderStartEvents[0]

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader.html:14:
receivedPrerenderStopEvents[1] = true;
receivedPrerenderStopEvents[0]

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader_removing_links.html (right):

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:15:
ExtractGetParameterBadlyAndInsecurely('links_to_insert', 1);
nit:  4 space indent.

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:35: <p
id=paragraph></p>
Is this needed?  I don't mind, just don't see it being used anywhere.

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:45:
PrerenderStopHandlerForLink.bind(null, i), false);
nit:  Replace tabs with spaces.

[gavinp, 2012-12-17 21:23:23]

Thanks for the reviews!

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader.html (right):

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader.html:10:
receivedPrerenderStartEvents[1] = true;
On 2012/12/17 20:47:53, Matt Menke wrote:
> receivedPrerenderStartEvents[0]

Done.

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader.html:14:
receivedPrerenderStopEvents[1] = true;
On 2012/12/17 20:47:53, Matt Menke wrote:
> receivedPrerenderStopEvents[0]

Done.

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
File chrome/test/data/prerender/prerender_loader_removing_links.html (right):

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:15:
ExtractGetParameterBadlyAndInsecurely('links_to_insert', 1);
On 2012/12/17 20:47:53, Matt Menke wrote:
> nit:  4 space indent.

Done.

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:35: <p
id=paragraph></p>
On 2012/12/17 20:47:53, Matt Menke wrote:
> Is this needed?  I don't mind, just don't see it being used anywhere.

No, that's leftover from a debug session. Now cut.

https://codereview.chromium.org/11459003/diff/63001/chrome/test/data/prerende...
chrome/test/data/prerender/prerender_loader_removing_links.html:45:
PrerenderStopHandlerForLink.bind(null, i), false);
On 2012/12/17 20:47:53, Matt Menke wrote:
> nit:  Replace tabs with spaces.

Done.

[commit-bot: I haz the power, 2012-12-17 21:45:50]

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

[commit-bot: I haz the power, 2012-12-17 23:31:47]

Failed to trigger a try job on mac_rel
HTTP Error 400: Bad Request

[commit-bot: I haz the power, 2012-12-17 23:32:03]

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

[commit-bot: I haz the power, 2012-12-18 01:01:41]

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

[commit-bot: I haz the power, 2012-12-18 01:51:51]

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

[commit-bot: I haz the power, 2012-12-18 02:23:55]

Change committed as 173625