(Possibly this should be moved to the platform-architecture-dev or chromium-mojo mailing list, if the answer isn't obvious to either of you.)

I don't think we want to allow WTF things in content/, so #2 seems an acceptable temp solution.

Please see https://bugs.chromium.org/p/chromium/issues/detail?id=610415 for previous discussion for the bluetooth case. AFAIK, the bluetooth code is supposed to be onion-souped so the current solution is temporary.

Permissions should also be Onion Souped :)

While I definitely agree that not relying on WTF in //content/ would be the cleanest option, this creates for some practical issues in Onion Soup migration ordering.

To give an example, the event dispatching machinery for Service Workers still lives in //content/, which is non-trivial to migrate.

For features building on top of that, given option (2) and until Service Workers gets souped, would we have the browser->renderer Mojo services living in //content using the regular Mojo variant, pass those types to Blink, then have regular->Blink mojo variant converters living in Blink?

That's *a lot* of additional plumbing.

Could we instead consider a policy where it's OK to use WTF (through Mojo) in //content/{child,renderer}/ when said feature is intended to be Onion Souped?

The alternative is to block souping such features (push, notifications) until their dependencies (Service Workers) have boiled.

Is it true that all we care about is enum? Maybe the custom typemapping feature is useful here?

Instead of using a mojo-defined enum type Foo in WebKit public API, we can use a C++-defined enum type CustomFoo.

Mojo supports custom typemapping for enum. Two ways to do it:
- Fully define Foo in mojom, and provide an EnumTraits to convert between CustomFoo and Foo.
- Declare Foo in mojom as a native-only enum (no definition), and use IPC::ParamTraits to convert between CustomFoo and Foo.

Either way, we can generate Mojo interfaces (blink/non-blink variants) to directly use CustomFoo as parameters.

All of that seems worse than just generating a -enums.h header separate from the interface. It's less manual, keeps the whole api in the .mojom, and solves this issue everywhere instead of as a one off every time.

Having the blink-variant interfaces depend on the non-blink-variant enum types may be a little confusing since the two are not in the same namespace.

I guess I just haven't understood why enum is special. Imagine we have a simple mojo struct:

struct Size {
  int32 x;
  int32 y;
};

The generated result is nothing WTF-specific. Do we want to allow Size in WebKit public API and generate a separate header for it to be shared between blink/non-blink variants? I guess the answer is probably "no".

WDYT? Thanks!

Hmm, that is true :/

#6, it's not just a matter of policy allowing the includes in particular files.

Code in WTF expects include dirs, build flags, etc. that aren't specified (leading to unexpected breakage like the one that made me open this bug). We could make //content/{renderer,child,...} explicitly depend on WTF, but that is a pretty big change.

Renaming Blink>Architecture to Blink>Internals

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4db41c4c92314447a07a2255d97c344547f97ce7

commit 4db41c4c92314447a07a2255d97c344547f97ce7
Author: jbroman <jbroman@chromium.org>
Date: Fri Jun 24 17:40:51 2016

Reland: WTF: Simplify RefPtr::operator bool.

The problematic case in String::find on ARM should now be gone, and so this
should be both simpler and equally fast.

Comparing to nullptr is used to coerce to boolean to work around  bug 621177 
(even though this is usually not the preferred way to do this in Blink).

BUG= 607208 , 621177 

Review-Url: https://codereview.chromium.org/2090973002
Cr-Commit-Position: refs/heads/master@{#401897}

[modify] https://crrev.com/4db41c4c92314447a07a2255d97c344547f97ce7/third_party/WebKit/Source/wtf/PassRefPtr.h
[modify] https://crrev.com/4db41c4c92314447a07a2255d97c344547f97ce7/third_party/WebKit/Source/wtf/RefPtr.h

Fixed by ortuno's CL, https://codereview.chromium.org/2145993003