I filed this with the 'Available' status because I'm not gonna look at this anytime soon, is there any specific reason you want to assign this to me? :)

Should I do something specific to move this out of the bugcop queue or something?

Hmm.. Available is still recognized as untriaged on the bugcop queue.

tobiasjs@ and cmasso@ may have a better idea about triaging this issue, but
since webview component is more like a platform rather than a real component, and we may need to triage tons of other issues that end up getting assigned to people outside webview team, I'm not sure if 'available' model is very effective in this case.

I'm probably misunderstanding your point here - IMO we should have some state which says: this bug is available, and nobody is currently looking at it, so feel free to take a look. 'Available' seems like the best name for that state.

Assigning all bugs to people just means everyone will have tonnes of bugs assigned that will not be looked at ever.   

If a bug has an owner, then it should be assigned to the owner. It is ok to make an issue "available" but there should be no owner on it, so that someone else can get to get to own it. 

So if you think someone else could work on this, remove yourself as the owner and make it available.

Can we remove this from the bugcop queue somehow? I don't want bugcops to track this type of tasks every week.

Right, our P0,P1,P2 bugcop queue includes 'available' bugs but our P3 queue does not. We should probably avoid 'available' bugs in our P0,P1,P2 queue/query? 

If those bugs are available and don't have owner then yes we should remove from the bugcop queue. But if they have owners then they should be assigned to respective owner.

Nate, do you want to look into this? If not, or if you don't have time I'll do this.

Toby pointed out that static methods will require chromium-initialization from the support library glue layer since at the time you call a static WebView method you won't necessarily have called the WebView ctor. So we need some way of triggering the initialization currently done in WebViewChromiumFactoryProvider, from the support library glue layer - potentially we should just move the initialization to a lower layer.

I think the easiest way of doing this is to leave WebViewChromium.init() alone since it's called in the WebView ctor anyway, and expose the WebViewChromiumFactoryProvider.startYourEngines() method to the support library glue layer through the interface that will expose the rest of the method/members of WebViewChromiumFactoryProvider as well.

Please let us know QA manual verification steps if verifiable.Thanks

No QA verification necessary. This is just a refactor. If this had major issues, WebView would be totally broken for a lot of apps.

Oh, actually I was thinking of a separate change. This actually has no CLs on it. Still, no QA verification needed :)

Bulk edit: marking stale 'fixed' bugs as 'verified' since they don't need verification at this point.