Bug 54588 – [chromium] Roll Chromium DEPS to 75190

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Steve Lacey]

Chromium DEPS needs to roll forward.

[Steve Lacey]

Created attachment 82695 [details]
Patch

[James Robinson]

Comment on attachment 82695 [details]
Patch

R=me - let's let the EWs bots have a swing at this before cq+'ing just to be safe.

[WebKit Review Bot]

Attachment 82695 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/7919484

[James Robinson]

Welp.  Looks like upstream has added some more dependencies that didn't used to be there.

[Steve Lacey]

Created attachment 82702 [details]
Patch

[WebKit Review Bot]

Attachment 82702 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/7927356

[Steve Lacey]

Created attachment 82718 [details]
Patch

[Steve Lacey]

Includes new libjingle dependency.

[James Robinson]

This makes me sad :( Why does DumpRenderTree need libjingle?  What added this dependency?

[Steve Lacey]

+Albert

No idea why DumpRenderTree is now dependent on libjingle.

Albert - The only thing that depends on libjingle afaik is remoting. Any idea what would cause DumpRenderTree to now rely on it (changed sometime between now (Weds 5pm PST) and 30 hours ago (Tues, 11am PST).

[Albert J. Wong]

(In reply to comment #10)
> +Albert
> 
> No idea why DumpRenderTree is now dependent on libjingle.
> 
> Albert - The only thing that depends on libjingle afaik is remoting. Any idea what would cause DumpRenderTree to now rely on it (changed sometime between now (Weds 5pm PST) and 30 hours ago (Tues, 11am PST).

+Sergey

Actually, there's a few places that depend on libjingle (eg., sync).

Also, we're starting to use it in PPAPI (albeit to support remoting and similar use cases, but technically its a separate feature).

The CL that added the dependency is this:
   http://codereview.chromium.org/6478018

I think the larger question is if DRT needs to depend on PPAPI...it's just testing the webkit renderer right?  Do we actually need pepper plugins for that?

[James Robinson]

(In reply to comment #11)
> (In reply to comment #10)
> > +Albert
> > 
> > No idea why DumpRenderTree is now dependent on libjingle.
> > 
> > Albert - The only thing that depends on libjingle afaik is remoting. Any idea what would cause DumpRenderTree to now rely on it (changed sometime between now (Weds 5pm PST) and 30 hours ago (Tues, 11am PST).
> 
> +Sergey
> 
> Actually, there's a few places that depend on libjingle (eg., sync).
> 
> Also, we're starting to use it in PPAPI (albeit to support remoting and similar use cases, but technically its a separate feature).
> 
> The CL that added the dependency is this:
>    http://codereview.chromium.org/6478018
> 
> I think the larger question is if DRT needs to depend on PPAPI...it's just testing the webkit renderer right?  Do we actually need pepper plugins for that?

Indeed.  I think eventually we might want to run layout tests that test pepper plugins (we currently have layout tests for NPAPI plugins), but we don't currently have any such layout tests.

It sucks that we keep having to add more and more (large) dependencies to this checkout.  It increases the complexity of rolling, build+cycle times, and makes it harder to understand what's going on with the code.

[Sergey Ulanov]

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > +Albert
> > > 
> > > No idea why DumpRenderTree is now dependent on libjingle.
> > > 
> > > Albert - The only thing that depends on libjingle afaik is remoting. Any idea what would cause DumpRenderTree to now rely on it (changed sometime between now (Weds 5pm PST) and 30 hours ago (Tues, 11am PST).
> > 
> > +Sergey
> > 
> > Actually, there's a few places that depend on libjingle (eg., sync).
> > 
> > Also, we're starting to use it in PPAPI (albeit to support remoting and similar use cases, but technically its a separate feature).
> > 
> > The CL that added the dependency is this:
> >    http://codereview.chromium.org/6478018
> > 
> > I think the larger question is if DRT needs to depend on PPAPI...it's just testing the webkit renderer right?  Do we actually need pepper plugins for that?
> 
> Indeed.  I think eventually we might want to run layout tests that test pepper plugins (we currently have layout tests for NPAPI plugins), but we don't currently have any such layout tests.
> 
> It sucks that we keep having to add more and more (large) dependencies to this checkout.  It increases the complexity of rolling, build+cycle times, and makes it harder to understand what's going on with the code.

In future I plan to add an abstract interface for P2P, so it will be possible to mock it for layout tests, but I'm not sure if it worth it (do we need to test the full network stack in the layout tests?).

[Darin Fisher (:fishd, Google)]

DRT should not need to depend on PPAPI.  This dependency is just an artifact of the PPAPI implementation living in src/webkit/plugins/ppapi/ (within the chromium tree), and DRT depends on src/webkit.  We should ideally break this dependency since it serves no value.

[Steve Lacey]

Could we break the dependency later? Would like to roll DEPS...

[Darin Fisher (:fishd, Google)]

Comment on attachment 82718 [details]
Patch

Yes, of course.  Can you please make sure that happens?

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 82718 [details]:

http/tests/security/cross-frame-access-port-explicit-domain.html bug 54668 (author: [e-mail])
The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 82718 [details]
Patch

Clearing flags on attachment: 82718

Committed r78838: <http://trac.webkit.org/changeset/78838>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Steve Lacey]

(In reply to comment #16)
> (From update of attachment 82718 [details])
> Yes, of course.  Can you please make sure that happens?

http://code.google.com/p/chromium/issues/detail?id=73304