Bug 111146 – REGRESSION(r144398): put WebTestProxy::scheduleComposite back in place

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[chromium] put WebTestProxy::scheduleComposite back in place

Created attachment 190892 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

broke almost all compositing tests on content_shell

[Nico Weber]

Comment on attachment 190892 [details]
Patch

Can you mention where this was removed in the changelog?

Created attachment 190913 [details]
Patch for landing

Comment on attachment 190913 [details]
Patch for landing

Clearing flags on attachment: 190913

Committed r144433: <http://trac.webkit.org/changeset/144433>

All reviewed patches have been landed.  Closing bug.

[James Robinson]

This isn't a terribly good solution.  The basic problem here appears to be that WebTestProxy wants to intercept a call (scheduleComposite) that otherwise has no reason to go through any WebKit APIs.  I resolved this for DumpRenderTree by hooking a special call (DRTLayerTreeViewClient::ScheduleComposite) to DRT's test harness.  It looks like to maintain this behavior in content shell I'll have to hook up a call to WebTextProxy from content::RenderWidget somehow.  Is there an established pattern for this?

Having this WebTextProxy stuff live in the WebKit repo but need access to things that happen normally only inside the WebKit embedder is a big pain for refactors like this :(

(In reply to comment #8)
> This isn't a terribly good solution.  The basic problem here appears to be that WebTestProxy wants to intercept a call (scheduleComposite) that otherwise has no reason to go through any WebKit APIs.  I resolved this for DumpRenderTree by hooking a special call (DRTLayerTreeViewClient::ScheduleComposite) to DRT's test harness.  It looks like to maintain this behavior in content shell I'll have to hook up a call to WebTextProxy from content::RenderWidget somehow.  Is there an established pattern for this?

not really. I read through the code, and I think having the method on WebTestProxy is actually the cleanest solution. it's the only solution where only when running layout tests extra code is executed.

If we're adding some test code to renderwidget, we'd always execute the check whether we're in a test or not.

> 
> Having this WebTextProxy stuff live in the WebKit repo but need access to things that happen normally only inside the WebKit embedder is a big pain for refactors like this :(

Having it live in the content module would make it a big pain for any change to layout tests

[James Robinson]

Jochen and I chatted some more and I think we've sorted this out.  We'll keep scheduleComposite() on WebTestProxy and on RenderWidget and just remove it from WebWidgetClient.