MacViews: Guard Objective-C bits in content::WebContentsViewDelegate with __OBJC__

MacViews: Guard Objective-C bits in content::WebContentsViewDelegate with __OBJC__

Currently WebContentsViewDelegate has a mix of ObjectiveC and C++ code
guarded by #ifdef OS_MACOSX. This means, on Mac, it can only be included
in .mm files.

For views on Mac, we want to reuse the toolkit-views WCVD (and tests)
when hosting a WebContents in a views::Widget. So we can't convert
everything to .mm.

This CL changes the guards to use __OBJC__ and ensures the vtable is a
consistent size with the compile flags used on MacViews.

To reduce churn, the WCVD methods are given default implementations.
MacViews needs the other methods, currently guarded by USE_AURA, so
things get really complex without this.

BUG=399191
Committed: https://crrev.com/1914f8eaacd794447cb5e35d4e6628b9761b9ebe
Cr-Commit-Position: refs/heads/master@{#292349}

[tapted, 2014-08-27 14:09:10]

tapted@chromium.org changed reviewers:
+ avi@chromium.org

[tapted, 2014-08-27 14:09:10]

Hi Avi, could you please take a look?

(If you want to peek at what's in the pipeline, there's a WIP in crrev/489863004
which gets a webview working end-to-end)

https://codereview.chromium.org/507363002/diff/50001/content/browser/web_cont...
File content/browser/web_contents/web_contents_view_mac.mm (right):

https://codereview.chromium.org/507363002/diff/50001/content/browser/web_cont...
content/browser/web_contents/web_contents_view_mac.mm:308: : nil);
This is a bit simpler in patchset 3 - it can go back to that if
ShellWebContentsViewDelegate is given a different a different parent class on
Mac (either with #ifdefs or a separate interface/header). But I'm not sure
there's much gained.

[Avi (use Gerrit), 2014-08-27 14:57:37]

We have hit this problem many times before, and the way we've always solved it
is to use #if __OBJC__ to dual-define classes. Can we do that here?

In the worst case, I would much rather use a void* and declare it in the comment
to really be a NSObject<RenderWidgetHostViewMacDelegate>* than add the
complication of what you're proposing.

(Thanks for fixing the include blockers, though, on WCVD.)

[tapted, 2014-08-28 01:50:59]

PTAL

On 2014/08/27 14:57:37, Avi wrote:
> We have hit this problem many times before, and the way we've always solved it
> is to use #if __OBJC__ to dual-define classes. Can we do that here?

Done. I feel only a little evil doing this in a vtable :) - I was half expecting
a linker somewhere to complain, but everything seems happy.

See what you think of how it came out. An additional #if (OS_MACOSX) could hide
the method in some places, but it will force cross-platform implementors to
mimic the #ifdef pattern as well which gets a bit fiddly (it's similar to what I
tried initially in my WIP..).

[Avi (use Gerrit), 2014-08-28 03:33:32]

Hey, "rules" like the ODR are meant to be broken :)

[Avi (use Gerrit), 2014-08-28 03:34:44]

Whoo! LGTM

[tapted, 2014-08-28 03:48:29]

tapted@chromium.org changed reviewers:
+ boliu@chromium.org, oshima@chromium.org

[tapted, 2014-08-28 03:48:29]

+oshima for OWNERS in athena/content
+boliu for TBR for android_webview (just a header change for IWYU fallout)

(oshima: this is just removing a stub that's not needed, in case you never plan
to implement it. But I can just leave these if you prefer)

[boliu, 2014-08-28 03:53:44]

On 2014/08/28 03:48:29, tapted wrote:
> +oshima for OWNERS in athena/content
> +boliu for TBR for android_webview (just a header change for IWYU fallout)

lgtm

> 
> (oshima: this is just removing a stub that's not needed, in case you never
plan
> to implement it. But I can just leave these if you prefer)

[oshima, 2014-08-28 06:38:27]

athena/ lgtm

[tapted, 2014-08-28 07:12:19]

thanks all! (-TBR :)

[tapted, 2014-08-28 07:12:40]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2014-08-28 07:13:54]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/tapted@chromium.org/507363002/70001

[commit-bot: I haz the power, 2014-08-28 07:51:00]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win8_chromium_rel on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel...)

[commit-bot: I haz the power, 2014-08-28 08:26:04]

Committed patchset #5 (id:70001) as 1d0c3139888700a30a24b2f529a7bbb50a6ef995

[commit-bot: I haz the power, 2014-09-10 02:58:30]

Patchset 5 (id:??) landed as
https://crrev.com/1914f8eaacd794447cb5e35d4e6628b9761b9ebe
Cr-Commit-Position: refs/heads/master@{#292349}