WebKit/common and namespace / types (Was: Appropriate Directory for Common origin_trials Code)

[Kinuko Yasuda]

Hi,

A brief update and one bike-shedding question to the list.

So we have now WebKit/common and some code has started moving in.  I've added a short README.md that describes very basic things, like:

* Use chromium coding style, lower_case_file_names.cc

* Use chromium types (e.g. //base) rather than WebKit ones

* Use `blink` namespace

However one of the foreseeable issue is that using different type families in WebKit/Source and WebKit/common) within the same namespace ('blink') might make things a bit awkward.

One easy solution is to use yet another namespace, like blink::common or blink_common.

I didn't think this'd look super great but can't come up with a better idea.  Any thoughts on this?

On Tue, Jul 11, 2017 at 12:10 PM, Kinuko Yasuda <kin...@chromium.org> wrote:

On Tue, Jul 11, 2017 at 4:30 AM, Ian Clelland <icle...@chromium.org> wrote:

It sounds like there's support for third_party/WebKit/common/origin_trials, which will eventually become blink/common/origin_trials.

third_party/WebKit/common just needs DEPS/OWNERS/README.md, as far as I know. Kinuko, were you planning on including those?

Yep, I have a WIP CL that includes them, and can send it for review soon.

 

(I suppose you could add those as part of a CL that moves the origin trials code there, but if Kinuko is going to create that directory as part of a different CL, then I guess wait for that to land first)

On Mon, Jul 10, 2017 at 3:18 PM, Alex Vallée <ava...@chromium.org> wrote:

So, do we have a decision about where this common code should end up?

On Wed, Jul 5, 2017 at 11:31 PM, TAMURA, Kent <tk...@chromium.org> wrote:

For some reason, we should not mix Chromium-origin code and WebKit-origin code.  So //blink/common is preferable at this moment.

On Thu, Jul 6, 2017 at 11:42 AM, Kinuko Yasuda <kin...@chromium.org> wrote:

On Thu, Jul 6, 2017 at 11:32 AM, Kentaro Hara <har...@chromium.org> wrote:

On Thu, Jul 6, 2017 at 11:26 AM, Kinuko Yasuda <kin...@chromium.org> wrote:

For loading / networking we're really starting to have lots of code that needs to be moved around or shared between processes, so having a clear destination now where common code can live sounds great.  Either WebKit/common or blink/common sounds good, and +1 for having it in WebKit/common for now.

Let me clarify a bit as things are moving fast: so the top-level dependency around Blink and browser-side code would look something like

services/

  ... things that implement services, both Blink and browser-side code can depend on its public interfaces.

WebKit/common (or blink/common, at least eventually)

  ... things that belong to Web platform live, both Blink and browser-side code can depend on this.

components/

  ... used to be the place for various componentized features with mixed deps, we're starting to ban Blink from depending on it.

It's probably implied, but I propose we also move the components stuff that need to be referenced both from Blink and browser-side code into that directory, which will make our story a lot easier.  Not coincidentally all of them (namely MimeUtils and LinkHeader) are loading related, so I'll incorporate that into our WIP loading re-architecturing plan if that sounds right to people / jam / haraken.

Sounds reasonable to me!

Would you mind creating WebKit/common/ (if there's no objection on this thread until tomorrow)?

Sure I can, maybe after waiting for a day or so.

 

On Thu, Jul 6, 2017 at 10:11 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Wed, Jul 5, 2017 at 6:08 PM, Kentaro Hara <har...@chromium.org> wrote:

On Thu, Jul 6, 2017 at 3:00 AM, Jeremy Roman <jbr...@chromium.org> wrote:

On Wed, Jul 5, 2017 at 1:38 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:

On Wed, Jul 5, 2017 at 10:35 AM, Jeremy Roman <jbr...@chromium.org> wrote:

On Wed, Jul 5, 2017 at 1:00 PM, John Abd-El-Malek <j...@chromium.org> wrote:

Thinking about this more, I take this back. We should decide where the files go, and if we all agree on blink/public, then having a GN target (blink_shared/blink_common?)to match that is consistent with the rest of the code.

Such a target would be a little strange, because it would be located in third_party/WebKit/ but essentially follow Chromium rules, so that it could be used in the browser process without WTF etc. existing. That would mean STL/base types rather than WTF types, and so on.

I thought it was the long term plan to have the browser-process-side code of web platform features be part of blink as well (in some new blink/browser or similar directory)? Wouldn't we have to address such strangenesses anyway in that case? I'm not saying it might not be weird, but it seems like something we'll need to solve one way or another, even if we don't create a blink_common like target now.

Discussion is a little scattered between tkent (et al)'s "great mv" thread and haraken (et al)'s Onion Soup 2.0 doc, but IIUC we'll ultimately have something like:

blink/

  browser/

    ...

  common/ (maybe? seems kinda-implied by dglazkov's decider-hat ruling)

    ...

  renderer/

    bindings/

    core/

    controller/ (things left over from content/renderer/)

    modules/

    platform/

  tools/

  ...

Great summary! Yes, this is where we're going.

In that world, it does seem reasonable to say "blink/renderer/ principally uses WTF types; everything outside uses STL types" (and have an assert_no_deps from the other code on the renderer code). This does have a number of upsides compared to our current configuration.

If we make this directory today, where would it go? third_party/WebKit/public/ seems a little odd (because it's almost pure API today, and includes stuff only legal to call in the renderer), Source/ is that renderer code, and "common" doesn't exist yet.

Yeah, I agree with Jeremy. I'm not sure if it's a good idea to abuse WebKit/public/ since the public APIs will be gone after Onion Soup 2.0.

If my understanding's correct, making something like "third_party/WebKit/common/" (or maybe even "blink/common/"), in anticipation of a blink/browser/ and blink/common/ in the future, SGTM. If so, we'll definitely need to update READMEs and PRESUBMITs to agree.

+1 to creating third_party/WebKit/common/ or //blink/common/ (if Chromium side people are okay with creating it now).

From my pov, either is fine with me. I have a slight preference for third_party/WebKit/common/ because it's easier to understand until the src/blink move happens.

 

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw1CzwMNwrmN5oCSGFXg0GaxfGC9_c7E%3Dfzj0Pprk6QO5w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMWgRNbRqxSHHX8Wu1z4Z3ahq3E5kNTJm5aXaZaAQuX%3DnLTJNg%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJwg7svT0KqDcr2XQBoTo1UcakoqD79T1pDckzNujMZc4A09ng%40mail.gmail.com.

[Kentaro Hara]

I'd prefer using the 'blink' namespace for WebKit/common/ but am open for ideas :)

IIUC the long-term plan is to reorganize directories as follows:

- //blink/browser/... (//content/browser/ will move here)

- //blink/renderer/... (//content/renderer/ and //third_party/WebKit/ will move here)

- //blink/common/... (//third_party/WebKit/common/ will move here)

In that world all code under //blink should have the 'blink' namespace. So I think it would make sense to use the 'blink' namespace for WebKit/common/ now.

[Dimitri Glazkov]

That plan SGTM.

:DG<

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw1CzwMNwrmN5oCSGFXg0GaxfGC9_c7E%3Dfzj0Pprk6QO5w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMWgRNbRqxSHHX8Wu1z4Z3ahq3E5kNTJm5aXaZaAQuX%3DnLTJNg%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJwg7svT0KqDcr2XQBoTo1UcakoqD79T1pDckzNujMZc4A09ng%40mail.gmail.com.

[Marijn Kruisselbrink]

I'm not quite convinced that we won't end up with very awkward naming when code using "blink" types (wtf etc) and code using non-blink types (std/base) ends up in the same namespace. For example in one CL I'm working on I need structs for more or less the same thing in blink/common and blink/renderer, one with std/base types, and one using blink/wtf types (both these then end up type-mapped to the same mojom struct; can't use the generated bindings directly because that would require too many unneeded copies). If both are in the blink namespace I'll need to somehow distinguish the two types in some other way, but not sure how. Have a blink::FooBar and blink::BlinkFooBar? Or maybe a blink::CommonFooBar and a blink::FooBar, but that feels wrong too, since there isn't anything "common" about the non-blink-typed one. It just uses different types.

Hopefully situations where we want classes to represent the same thing in both blink/common and blink/renderer are rare (i.e. either we can just use the blink/common type all throughout blink/renderer, or these are situations where the auto-generated mojom bindings work), but this does seem like something that can come up more than just the one case I'm currently running into. Another benefit of separate namespaces would be that it is obvious what types are being used by a particular class. If common and renderer use the same namespace you'll have to actually figure out which header a type is defined in before you know what strings/vectors/etc types it uses.

That plan SGTM.

:DG<

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw1CzwMNwrmN5oCSGFXg0GaxfGC9_c7E%3Dfzj0Pprk6QO5w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMWgRNbRqxSHHX8Wu1z4Z3ahq3E5kNTJm5aXaZaAQuX%3DnLTJNg%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJwg7svT0KqDcr2XQBoTo1UcakoqD79T1pDckzNujMZc4A09ng%40mail.gmail.com.

[Kinuko Yasuda]

Consistently using 'blink' namespace is my preference as well, but what mek@ wrote is the concern I had too.  Let me try to rephrase it once again to make sure we're on the same page:

Today it's very obvious that blink::FooBar uses blink-flavored types, while, say, content::FooBar doesn't.

Similarly, we use mojom::blink::Foo for blink-flavored mojo code while mojom::Foo does not.

So far we've been using the namespace conveniently tied with the type flavor we use, but we'll be breaking this in WebKit/common (and browser one, when we have it).

For example we'll be using mojom::Foo but in blink:: namespace.  We might need to be having blink::BlinkFoo and blink::Foo when we have two impls of the same interface with different flavors.

This is probably just ok but could be confusing.  If any of you have other ideas / thoughts on this point that'd be welcome.  (Or I'll update the doc to clarify this point)

That plan SGTM.

:DG<

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw1CzwMNwrmN5oCSGFXg0GaxfGC9_c7E%3Dfzj0Pprk6QO5w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMWgRNbRqxSHHX8Wu1z4Z3ahq3E5kNTJm5aXaZaAQuX%3DnLTJNg%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJwg7svT0KqDcr2XQBoTo1UcakoqD79T1pDckzNujMZc4A09ng%40mail.gmail.com.

[Kentaro Hara]

Thanks, I understand your point.

To avoid the confusion you mentioned, do we probably need to have different namespaces for //blink/common/, //blink/browser/ and //blink/renderer/?

[Kinuko Yasuda]

Yeah. Trying to have some consensus, here's another idea:

"blink" for renderer code

"blink_platform" for common and browser code (they don't really need to use different namespace)

How does it sound?

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzhY447t%2BqmNZwPVzd5KCKXe1Hv8WVCo9gJigLdWfocow%40mail.gmail.com.

[John Abd-El-Malek]

I'm curious to learn more about Marijn's case. We should try to find a cheap way of reusing the mojo structure. Defining two C++ versions and typemaps is something we're trying to avoid.

Until then, unless we know there's no other way and that this situation will be widespread, I'd try to avoid different namespaces. It's not consistent with other directories that have browser/renderer code, and also against the general guideline of src/foo uses foo:: namespace.

How does it sound?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzhY447t%2BqmNZwPVzd5KCKXe1Hv8WVCo9gJigLdWfocow%40mail.gmail.com.

[Yuta Kitamura]

As an additional request, I'd like to move namespace "WTF" to somewhere that makes more sense. Maybe we can give the same namespace as other platform/ stuff.

How does it sound?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzhY447t%2BqmNZwPVzd5KCKXe1Hv8WVCo9gJigLdWfocow%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMWgRNbhUkAKWkX%2Bof%2BDEh5T_sb_pCjur9RVe%2BnM4k0oujmR7g%40mail.gmail.com.

[Marijn Kruisselbrink]

On Tue, Aug 8, 2017 at 9:04 PM, John Abd-El-Malek <j...@chromium.org> wrote:

I'm curious to learn more about Marijn's case. We should try to find a cheap way of reusing the mojo structure. Defining two C++ versions and typemaps is something we're trying to avoid.

My particular case is a bit special probably. Using a struct to represent a message passed over a postMessage API (i.e. a blink::SerializedScriptValue). Using typemaps to two different c++ structs allows me to reduce copies of the data as much as possible: it lets me directly serialize from/to the SerializedScriptValue's internal buffer in the renderer, and it lets me broadcast out messages in the browser side for BroadcastChannel without having to make extra copies of the data for each pipe on which the message needs to be broadcasted.

Until then, unless we know there's no other way and that this situation will be widespread, I'd try to avoid different namespaces. It's not consistent with other directories that have browser/renderer code, and also against the general guideline of src/foo uses foo:: namespace.

Other directories that have browser/renderer code don't use different types for browser and renderer code though. I think part of the problem here is the overloaded use of "blink". It is both: the name of the (eventual) top-level directory, ad the name of the mojo bindings variant used in one particular subdirectory of that top-level directory (and more colloquially "blink types" is used to refer to the types used in blink renderer code). That already leads to weirdness with mojo bindings (a blink::mojom::blink namespace always seems awkward to me), and it feels like it would only get weirder.

 

On Tue, Aug 8, 2017 at 8:17 PM, Kinuko Yasuda <kin...@chromium.org> wrote:

Yeah. Trying to have some consensus, here's another idea:

"blink" for renderer code

"blink_platform" for common and browser code (they don't really need to use different namespace)

Agreed that common and browser code don't need different namespaces. Not sure "platform" makes the most sense though, as that seems like it would get confusing with the existing Source/platform? Not sure I have any better suggestions though, if we're stuck with using the name "blink" for both the top-level concept, as well as the type-system used in the renderer subset of that top-level concept.

[Marijn Kruisselbrink]

On Thu, Aug 10, 2017 at 11:45 AM, Marijn Kruisselbrink <m...@chromium.org> wrote:

On Tue, Aug 8, 2017 at 9:04 PM, John Abd-El-Malek <j...@chromium.org> wrote:

I'm curious to learn more about Marijn's case. We should try to find a cheap way of reusing the mojo structure. Defining two C++ versions and typemaps is something we're trying to avoid.

My particular case is a bit special probably. Using a struct to represent a message passed over a postMessage API (i.e. a blink::SerializedScriptValue). Using typemaps to two different c++ structs allows me to reduce copies of the data as much as possible: it lets me directly serialize from/to the SerializedScriptValue's internal buffer in the renderer, and it lets me broadcast out messages in the browser side for BroadcastChannel without having to make extra copies of the data for each pipe on which the message needs to be broadcasted.

(and a related, but not quite as hard case I'm currently running in to is what to do with content::MessagePort vs blink::MessagePort, where I'm trying to move the former to WebKit/common. But there at least I can come up with somewhat plausible names to rename one or the other... just what I'll actually end up doing depends on the outcome of this discussion).

[Kentaro Hara]

I'm not planning to mess up this discussion but let me propose another option:

- Use the same 'blink::' namespace for //blink/{browser,renderer,common}

- Rename 'mojom::blink::' to 'mojom::renderer::'. Then //blink/renderer/ should use 'mojom::renderer::' and //blink/browser/ should use 'mojom::'.

Any thoughts?

[John Abd-El-Malek]

On Sun, Aug 13, 2017 at 11:20 PM, Kentaro Hara <har...@chromium.org> wrote:

I'm not planning to mess up this discussion but let me propose another option:

- Use the same 'blink::' namespace for //blink/{browser,renderer,common}

- Rename 'mojom::blink::' to 'mojom::renderer::'. Then //blink/renderer/ should use 'mojom::renderer::' and //blink/browser/ should use 'mojom::'.

Any thoughts?

My impression is that the benefit of changing this depends on how often the cases that a blink:: type would have the same name as the mojom type. I think it's still not clear that this is a widespread problem?

[Yuzhu Shen]

On Sun, Aug 13, 2017 at 11:20 PM, Kentaro Hara <har...@chromium.org> wrote:

I'm not planning to mess up this discussion but let me propose another option:

- Use the same 'blink::' namespace for //blink/{browser,renderer,common}

- Rename 'mojom::blink::' to 'mojom::renderer::'. Then //blink/renderer/ should use 'mojom::renderer::' and //blink/browser/ should use 'mojom::'.

Any thoughts?

Using "renderer" as the variant name doesn't seem to clearly convey the idea that it uses "blink-specific renderer-side types". For example, imagine we have a mojom type outside of blink/ called foo.mojom.Bar, then:

- chromium-flavored generated code: foo::mojom::Bar;

- blink-renderer-flavored generated code: foo::mojom::renderer::Bar.

The problem is, foo::mojom::renderer::Bar doesn't say anything that it is blink-specific. Besides, foo::mojom::Bar could by used by renderer-side *non-blink* code.

Could we come up with a name for "blink-specific renderer-side types"? Does "wtf" seem a terrible idea?

[Kentaro Hara]

Could we come up with a name for "blink-specific renderer-side types"? Does "wtf" seem a terrible idea?

Once Onion Soup 2.0 is done, platform/wtf/ is going to be a "blink-specific renderer-side" library. So using "wtf" doesn't sound a bad idea to me.

In short term, shall we go with Jam's proposal? In other words:

- Use the same 'blink::' namespace for //blink/{browser,renderer,common}.

- See how much it confuses Mojo bindings. If it's too much, we can consider renaming 'mojom::blink::' to 'mojom::wtf::' or something.

[Kinuko Yasuda]

On Tue, Aug 15, 2017 at 9:34 AM, Kentaro Hara <har...@chromium.org> wrote:

Could we come up with a name for "blink-specific renderer-side types"? Does "wtf" seem a terrible idea?

Once Onion Soup 2.0 is done, platform/wtf/ is going to be a "blink-specific renderer-side" library. So using "wtf" doesn't sound a bad idea to me.

In short term, shall we go with Jam's proposal? In other words:

- Use the same 'blink::' namespace for //blink/{browser,renderer,common}.

- See how much it confuses Mojo bindings. If it's too much, we can consider renaming 'mojom::blink::' to 'mojom::wtf::' or something.

I haven't made it very clear but that's the current state and blocking other work by this discussion is not my intention, so +1.

We can keep / resume this discussion when more code comes in / more patterns start to appear.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwRK%2Bd8nrL195yDbhz4%2BvYyA%2BtOQ_m-SRKnr%3DLJrA%3Dj7g%40mail.gmail.com.

[Yuzhu Shen]

On Mon, Aug 14, 2017 at 5:34 PM, Kentaro Hara <har...@chromium.org> wrote:

Could we come up with a name for "blink-specific renderer-side types"? Does "wtf" seem a terrible idea?

Once Onion Soup 2.0 is done, platform/wtf/ is going to be a "blink-specific renderer-side" library. So using "wtf" doesn't sound a bad idea to me.

In short term, shall we go with Jam's proposal? In other words:

- Use the same 'blink::' namespace for //blink/{browser,renderer,common}.

- See how much it confuses Mojo bindings. If it's too much, we can consider renaming 'mojom::blink::' to 'mojom::wtf::' or something.

Sounds good to me. Thanks!