Implement AwContentRendererClient and remove chrome/ dependency

Implement AwContentRendererClient and remove chrome/ dependency

BUG=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=161409

[boliu, 2012-10-10 00:19:04]

Uploading now as an fyi. No nit reviews unless you really want...

Currently overriding all methods and have comments in the body about what I
think should be done. Most of the methods without TODOs should be removed and
use the default implementation.

This compiles and does not break upstream instrumentation tests (these
functionality aren't really covered by these tests). I have not tried cts tests
yet.

[boliu, 2012-10-10 00:24:40]

http://codereview.chromium.org/11096036/diff/1/android_webview/lib/DEPS
File android_webview/lib/DEPS (right):

http://codereview.chromium.org/11096036/diff/1/android_webview/lib/DEPS#newco...
android_webview/lib/DEPS:10:
"!third_party/WebKit/Source/WebKit/chromium/public/WebSecurityPolicy.h",
These two can be removed too.

[joth, 2012-10-10 02:25:24]

wow what a lot of... stuff...!

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
File android_webview/renderer/aw_content_renderer_client.cc (right):

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:71: std::string*
error_domain) {
indent

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:105: // default.
the important thing not documented clearly is  the idle handler is needed for
resource cleanup.  (not scheduling background JS work).

so, yes we definitely want to reclaim resources when the widget is hidden.

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:111: // default is not
allow pop up.
again the docs for this method are not good (even, the name of the function is
bad).
the main effect of "return true" is it causes the IPC sent to browser to "lie"
and have user_gesture == true even if it wasn't a user gesture.

I can't see us having a use case for that (as we need to accurately report
userGesture in WebChromeClient.onCreateWindow and the embedder can easily chose
to ignore that param if it wants to treat the request as a user gesture even
when it wasn't...)

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:120: // so returning the
default false here.
not just extensions, pre-render stuff too.
For us, there's also the fact  we're single process....

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:129: // so returning the
default false here.
again weird function name... this one's about URL re-writing. (allows embedder
to switch url to new_url)

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:134: // Default and
chrome implementation both return true. But I'm not sure if
i see them both returning false

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:135: // this is useful to
our cookie manager implementation.
completely disconnected with our cookie manager impl, as we don't allow cookie
blocker popups. return false seems correct.

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:161: // Perhaps
compotenize the chrome implementation?
hmm componentize the hashing function, or the whole shared mem threading
solution?

in webview this needs to tie into WebViewClient.doUpdateVisitedHistory
(b/6202898) and WebChromeClient.getVisitedHistory  (b/6295504). could mention
this in the TODO too.

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:167: // Perhaps
compotenize the chrome implementation?
may just want to raise a crbug for this one and move on.

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:183: // path (which is
what??). Seems only to be used for chrome frame.
which would involve IPC... and eventually pop out at
AwCookieAccessPolicy::OnCan[Set|Get]Cookies

[mnaganov (inactive), 2012-10-10 08:45:16]

http://codereview.chromium.org/11096036/diff/1/android_webview/lib/DEPS
File android_webview/lib/DEPS (right):

http://codereview.chromium.org/11096036/diff/1/android_webview/lib/DEPS#newco...
android_webview/lib/DEPS:10:
"!third_party/WebKit/Source/WebKit/chromium/public/WebSecurityPolicy.h",
On 2012/10/10 00:24:40, boliu wrote:
> These two can be removed too.

Yes, please. You moved the registration code into aw_content_renderer_client.cc

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
File android_webview/renderer/aw_content_renderer_client.cc (right):

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:48: return
std::string("ISO-8859-1");
I guess, that's different from locale. In WebSettingsClassic, the default
encoding is read from com.android.internal.R.string.default_text_encoding. See
frameworks/base/core/res/res/values/donottranslate.xml Almost always, the value
is "Latin-1", except for Japanese resources, where the value is "Shift_JIS".

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:105: // default.
On 2012/10/10 02:25:25, joth wrote:
> the important thing not documented clearly is  the idle handler is needed for
> resource cleanup.  (not scheduling background JS work).
> 
> so, yes we definitely want to reclaim resources when the widget is hidden.

Looking at RenderThreadImpl::IdleHandler(), it is used for releasing free memory
to system and running V8's garbage collection. It doesn't seem to free any other
kinds of resources.

[mkosiba (inactive), 2012-10-10 09:22:21]

Good stuff!

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
File android_webview/renderer/aw_content_renderer_client.cc (right):

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:81: // TODO(boliu):
Implement our own error pages
it's more of a TODO(benm) really ;)

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:115: bool
AwContentRendererClient::ShouldFork(WebKit::WebFrame* frame,
nit: indent (here and later): IIRC arguments must be aligned to the first
argument.

[benm (inactive), 2012-10-10 10:05:30]

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
File android_webview/renderer/aw_content_renderer_client.cc (right):

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:38: // No-op. For used
for crash report.
used for

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:48: return
std::string("ISO-8859-1");
I have a change in progress that will allow us to read the framework strings,
feel free to give me this todo

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:72: // TODO(boliu):
Implement our own error pages
I've been looking into how we can display our error pages from the framework
resources, I can take this TODO

http://codereview.chromium.org/11096036/diff/1/android_webview/renderer/aw_co...
android_webview/renderer/aw_content_renderer_client.cc:81: // TODO(boliu):
Implement our own error pages
On 2012/10/10 09:22:21, Martin Kosiba wrote:
> it's more of a TODO(benm) really ;)

yep, i've been looking into how we can hook this up, please feel free to assign
to me

[boliu, 2012-10-11 01:24:05]

This is not breaking instrumentation tests or cts tests (previous cts failure
was due to bad android version).

Probably should file bugs for the TODOs, with various levels of priorities. But
I think this can be submitted now.

Also I think the names in TODOs doesn't mean who's assigned to fix it, just who
to talk to to get information, so...leaving everything as me ;)

http://codereview.chromium.org/11096036/diff/8008/android_webview/renderer/aw...
File android_webview/renderer/aw_content_renderer_client.cc (right):

http://codereview.chromium.org/11096036/diff/8008/android_webview/renderer/aw...
android_webview/renderer/aw_content_renderer_client.cc:39: return
std::string("ISO-8859-1");
This is the value for us-en in the chrome implementation, so not using Latin-1.

[joth, 2012-10-11 17:41:52]

lgtm

[commit-bot: I haz the power, 2012-10-11 17:42:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11096036/8008

[commit-bot: I haz the power, 2012-10-11 18:04:29]

Sorry for I got bad news for ya.
Compile failed with a clobber build.
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2012-10-11 19:08:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11096036/8008

[boliu, 2012-10-11 20:07:37]

Hmm...looks like the android_fyi_dbg bot crash wasn't spurious, something
between Patchset 2 and 3 broke it :|

[boliu, 2012-10-11 20:25:31]

On 2012/10/11 20:07:37, boliu wrote:
> Hmm...looks like the android_fyi_dbg bot crash wasn't spurious, something
> between Patchset 2 and 3 broke it :|

Or it was spurious...locally as well...failed once out of about 20 runs.

[commit-bot: I haz the power, 2012-10-11 20:26:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11096036/8008

[commit-bot: I haz the power, 2012-10-11 21:41:12]

Change committed as 161409