Converts GURL's constructor to take StringPieces instead of std::string to
avoid extra copies when converting from constants (which is fairly common).
Adds a WebStringToGURL helper function. The above change broke the ability
to give a WebString to GURL's constructor because that relied on the implicit
string16 conversion on WebString which will no longer match GURL.
This helper function will also eliminate a string copy for almost every
WebString to GURL conversion. Normally if a WebString contains a URL, it will
be ASCII. The old code would convert this ASCII to a temporary base::string16
just to pass into GURL, which can take either type (and will convert to
8-bit in the end either way).
This exposes the internal 8- and 16-bit buffers via new getters. This allows
the underlying buffers to be passed directly to GURL in the native format
without copying.
An alternative to exposing these getters would be to make the conversion
function a friend, or adding a GURL getter directly on WebString. But this
seems like the wrong type of function to have on a string class. There are a
number of other modules in Chrome that can take either 8 or 16 bit strings that
may be able to re-use this for performance-critical places.
The mojo implicit string conversion was similarly broken. In these cases, this
patch just adds a manual get() function call to retrieve the underlying
std::string rather than relying on the implicit conversion.
Media doesn't depend on content (where I put the helper function) and there
were only a few WebString -> GURL conversions there, so I did an explicit
string16 constructor for those (matching the current implicit behavior).
Review URL: https://codereview.chromium.org/1568073002
Cr-Commit-Position: refs/heads/master@{#370274}
This directory is for features that are intended for reuse across multiple
embedders (e.g., Android WebView and Chrome).
By default, components can depend only on the lower layers of the Chromium
codebase(e.g. base/, net/, etc.). Individual components may additionally allow
dependencies on the content API and IPC; however, if such a component is used
by Chrome for iOS (which does not use the content API or IPC), the component
will have to be in the form of a layered component
(http://www.chromium.org/developers/design-documents/layered-components-design).
Components that have bits of code that need to live in different
processes (e.g. some code in the browser process, some in the renderer
process, etc.) should separate the code into different subdirectories.
Hence for a component named 'foo' you might end up with a structure
like the following (assuming that foo is not used by iOS and thus does not
need to be a layered component):
components/foo - DEPS, OWNERS, foo.gypi
components/foo/browser - code that needs the browser process
components/foo/common - for e.g. IPC constants and such
components/foo/renderer - code that needs renderer process
These subdirectories should have DEPS files with the relevant
restrictions in place, i.e. only components/*/browser should
be allowed to #include from content/public/browser.
Note that there may also be an 'android' subdir, with a Java source
code structure underneath it where the package name is
org.chromium.components.foo, and with subdirs after 'foo'
to illustrate process, e.g. 'browser' or 'renderer':
components/foo/android/OWNERS, DEPS
components/foo/android/java/src/org/chromium/components/foo/browser/
components/foo/android/javatests/src/org/chromium/components/foo/browser/
Code in a component should be placed in a namespace corresponding to
the name of the component; e.g. for a component living in
//components/foo, code in that component should be in the foo::
namespace.
dfbcc3b792