Exposes OrientationChangeEvent.

Exposes OrientationChangeEvent.

Depends on https://bugs.webkit.org/show_bug.cgi?id=85976.
This is used by chrome on android.

BUG=
TEST=


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

[bulach, 2012-05-09 12:03:18]

duh :( my bad: try jobs will fail until we roll to the webkit patch.

[jam, 2012-05-14 06:09:54]

http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
File content/public/browser/render_view_host.h (right):

http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
content/public/browser/render_view_host.h:248: // User rotated the screen. Calls
the "onorientationchange" Javascript hook.
where will the code that call this reside, i.e. in content/ or chrome/ ? if in
content/, this doesn't need to be exposed on the public API

[bulach, 2012-05-14 11:59:30]

thanks jam! reply and follow up question below:

http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
File content/public/browser/render_view_host.h (right):

http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
content/public/browser/render_view_host.h:248: // User rotated the screen. Calls
the "onorientationchange" Javascript hook.
On 2012/05/14 06:09:54, John Abd-El-Malek wrote:
> where will the code that call this reside, i.e. in content/ or chrome/ ? if in
> content/, this doesn't need to be exposed on the public API

really good point! until a couple of days ago :) this was called by an object
that just got renamed / moved to ContentView donwstream.

I'll fix that, but just to make it right: I see a few places that static_cast a
RenderViewHost down to a RenderViewHostImpl, and some other places that use the
RVH to directly send the IPC message. which one is the preferred way?

(our ContentsView, which is essentially a conduit to/from the java side, has a
WebContents, which gives it access to a RVH)

[jam, 2012-05-14 15:20:49]

On 2012/05/14 11:59:30, bulach wrote:
> thanks jam! reply and follow up question below:
> 
>
http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
> File content/public/browser/render_view_host.h (right):
> 
>
http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
> content/public/browser/render_view_host.h:248: // User rotated the screen.
Calls
> the "onorientationchange" Javascript hook.
> On 2012/05/14 06:09:54, John Abd-El-Malek wrote:
> > where will the code that call this reside, i.e. in content/ or chrome/ ? if
in
> > content/, this doesn't need to be exposed on the public API
> 
> really good point! until a couple of days ago :) this was called by an object
> that just got renamed / moved to ContentView donwstream.

and just to be clear, ContentView is going to be under src/content?

> 
> I'll fix that, but just to make it right: I see a few places that static_cast
a
> RenderViewHost down to a RenderViewHostImpl, and some other places that use
the
> RVH to directly send the IPC message. which one is the preferred way?

In general one should cast only when needed. so when using the Send method,
which is on RVH, just use the RVH directly. Only when needing methods on the
RVHImpl should a cast be done.

> 
> (our ContentsView, which is essentially a conduit to/from the java side, has a
> WebContents, which gives it access to a RVH)

[bulach, 2012-05-14 15:39:30]

On 2012/05/14 15:20:49, John Abd-El-Malek wrote:
> On 2012/05/14 11:59:30, bulach wrote:
> > thanks jam! reply and follow up question below:
> > 
> >
>
http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
> > File content/public/browser/render_view_host.h (right):
> > 
> >
>
http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
> > content/public/browser/render_view_host.h:248: // User rotated the screen.
> Calls
> > the "onorientationchange" Javascript hook.
> > On 2012/05/14 06:09:54, John Abd-El-Malek wrote:
> > > where will the code that call this reside, i.e. in content/ or chrome/ ?
if
> in
> > > content/, this doesn't need to be exposed on the public API
> > 
> > really good point! until a couple of days ago :) this was called by an
object
> > that just got renamed / moved to ContentView donwstream.
> 
> and just to be clear, ContentView is going to be under src/content?

that's right.

> 
> > 
> > I'll fix that, but just to make it right: I see a few places that
static_cast
> a
> > RenderViewHost down to a RenderViewHostImpl, and some other places that use
> the
> > RVH to directly send the IPC message. which one is the preferred way?
> 
> In general one should cast only when needed. so when using the Send method,
> which is on RVH, just use the RVH directly. Only when needing methods on the
> RVHImpl should a cast be done.

sorry, my question wasn't clear.. :)
should I expose a method in RVHImpl and do static_cast down or is it better to
just Send the message directly from our side?

> 
> > 
> > (our ContentsView, which is essentially a conduit to/from the java side, has
a
> > WebContents, which gives it access to a RVH)

[jam, 2012-05-14 15:47:31]

On 2012/05/14 15:39:30, bulach wrote:
> On 2012/05/14 15:20:49, John Abd-El-Malek wrote:
> > On 2012/05/14 11:59:30, bulach wrote:
> > > thanks jam! reply and follow up question below:
> > > 
> > >
> >
>
http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
> > > File content/public/browser/render_view_host.h (right):
> > > 
> > >
> >
>
http://codereview.chromium.org/10388045/diff/1/content/public/browser/render_...
> > > content/public/browser/render_view_host.h:248: // User rotated the screen.
> > Calls
> > > the "onorientationchange" Javascript hook.
> > > On 2012/05/14 06:09:54, John Abd-El-Malek wrote:
> > > > where will the code that call this reside, i.e. in content/ or chrome/ ?
> if
> > in
> > > > content/, this doesn't need to be exposed on the public API
> > > 
> > > really good point! until a couple of days ago :) this was called by an
> object
> > > that just got renamed / moved to ContentView donwstream.
> > 
> > and just to be clear, ContentView is going to be under src/content?
> 
> that's right.
> 
> > 
> > > 
> > > I'll fix that, but just to make it right: I see a few places that
> static_cast
> > a
> > > RenderViewHost down to a RenderViewHostImpl, and some other places that
use
> > the
> > > RVH to directly send the IPC message. which one is the preferred way?
> > 
> > In general one should cast only when needed. so when using the Send method,
> > which is on RVH, just use the RVH directly. Only when needing methods on the
> > RVHImpl should a cast be done.
> 
> sorry, my question wasn't clear.. :)
> should I expose a method in RVHImpl and do static_cast down or is it better to
> just Send the message directly from our side?

I'd just put it on RVHImpl. The reason is that the IPC/renderer side isn't
android specific, so it might be more consistent to have the sending side also
be cross platform.

> 
> > 
> > > 
> > > (our ContentsView, which is essentially a conduit to/from the java side,
has
> a
> > > WebContents, which gives it access to a RVH)

[bulach, 2012-05-14 17:10:49]

thanks!

addressed the comments and tried to clarify one comment, another look please?

http://codereview.chromium.org/10388045/diff/1007/content/browser/renderer_ho...
File content/browser/renderer_host/render_view_host_impl.h (right):

http://codereview.chromium.org/10388045/diff/1007/content/browser/renderer_ho...
content/browser/renderer_host/render_view_host_impl.h:416: // to keep them
consistent).
I tried to clarify this a bit, let me know if this works for you..

[jam, 2012-05-14 17:15:40]

lgtm

[commit-bot: I haz the power, 2012-05-15 09:13:35]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bulach@chromium.org/10388045/1007

[commit-bot: I haz the power, 2012-05-15 10:16:02]

The commit queue went berserk retrying too often for a
seemingly flaky test. Builder is android, revision is 137095, job name
was 10388045-1007 (previous was lost) (previous was lost) (previous was lost)
(previous was lost).

[commit-bot: I haz the power, 2012-05-15 13:07:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bulach@chromium.org/10388045/1007

[commit-bot: I haz the power, 2012-05-15 14:47:20]

Change committed as 137123