diff --git a/cc/animation/README.md b/cc/animation/README.md
index 7f68611486b542..12359aad36942f 100644
--- a/cc/animation/README.md
+++ b/cc/animation/README.md
@@ -157,5 +157,5 @@ base. [Smooth Scrolling in Chromium](https://goo.gl/XXwAwk) provides
an overview of smooth scrolling. There is further class header
documentation in
Blink's
-[platform/scroll](https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/platform/scroll/)
+[platform/scroll](https://codesearch.chromium.org/chromium/src/third_party/blink/renderer/platform/scroll/)
directory.
diff --git a/content/browser/bluetooth/README.md b/content/browser/bluetooth/README.md
index 87c06ffa87fb1c..e39aac5da16892 100644
--- a/content/browser/bluetooth/README.md
+++ b/content/browser/bluetooth/README.md
@@ -7,7 +7,7 @@ This service is exposed to the web in the [blink bluetooth module].
[Web Bluetooth specification]: https://webbluetoothcg.github.io/web-bluetooth/
[/device/bluetooth]: /device/bluetooth
-[blink bluetooth module]: /third_party/WebKit/Source/modules/bluetooth/
+[blink bluetooth module]: /third_party/blink/renderer/modules/bluetooth/
## Testing
diff --git a/content/browser/download/docs/save-page-as.md b/content/browser/download/docs/save-page-as.md
index cb6f38a5cee87b..4493bd6b9bad7d 100644
--- a/content/browser/download/docs/save-page-as.md
+++ b/content/browser/download/docs/save-page-as.md
@@ -130,11 +130,11 @@ Pointers to related code outside of `//content/browser/download`:
* `//content/renderer/savable_resources...`
* Blink:
- * `//third_party/WebKit/public/web/WebFrameSerializer...`
- * `//third_party/WebKit/Source/web/WebFrameSerializerImpl...`
+ * `//third_party/blink/public/web/web_frame_serializer...`
+ * `//third_party/blink/renderere/core/frame/web_frame_serializer_impl...`
(used for Complete HTML today; should use `FrameSerializer` instead in
the long-term - see https://crbug.com/328354).
- * `//third_party/WebKit/Source/core/frame/FrameSerializer...`
+ * `//third_party/blink/renderer/core/frame/frame_serializer...`
(used for MHTML today)
- * `//third_party/WebKit/Source/platform/mhtml/MHTMLArchive...`
+ * `//third_party/blink/renderer/platform/mhtml/mhtml_archive...`
diff --git a/device/bluetooth/test/README.md b/device/bluetooth/test/README.md
index 83619ca6e0fc86..7544bb3be52ff8 100644
--- a/device/bluetooth/test/README.md
+++ b/device/bluetooth/test/README.md
@@ -6,7 +6,7 @@ the Bluetooth component.
There are also notable higher level bluetooth tests:
* [Extensions](/extensions/browser/api/bluetooth/)
-* [Web Bluetooth](/third_party/WebKit/Source/modules/bluetooth/README.md)
+* [Web Bluetooth](/third_party/blink/renderer/modules/bluetooth/README.md)
## Client Testing
diff --git a/docs/accessibility/overview.md b/docs/accessibility/overview.md
index 36e4b14dad11a9..67cf8e1c6759f9 100644
--- a/docs/accessibility/overview.md
+++ b/docs/accessibility/overview.md
@@ -510,23 +510,23 @@ is defined by [automation.idl], which must be kept synchronized with
[AccessibilityHostMsg_EventParams]: https://cs.chromium.org/chromium/src/content/common/accessibility_messages.h?sq=package:chromium&l=75
[AutomationInternalCustomBindings]: https://cs.chromium.org/chromium/src/chrome/renderer/extensions/automation_internal_custom_bindings.h
[AXContentNodeData]: https://cs.chromium.org/chromium/src/content/common/ax_content_node_data.h
-[AXLayoutObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXLayoutObject.h
-[AXNodeObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXNodeObject.h
-[AXObjectImpl]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXObjectImpl.h
-[AXObjectCacheImpl]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.h
+[AXLayoutObject]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/accessibility/ax_layout_object.h
+[AXNodeObject]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/accessibility/ax_node_object.h
+[AXObjectImpl]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/accessibility/ax_object_impl.h
+[AXObjectCacheImpl]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/accessibility/ax_object_cache_impl.h
[AXPlatformNode]: https://cs.chromium.org/chromium/src/ui/accessibility/platform/ax_platform_node.h
[AXTreeSerializer]: https://cs.chromium.org/chromium/src/ui/accessibility/ax_tree_serializer.h
[BlinkAXTreeSource]: https://cs.chromium.org/chromium/src/content/renderer/accessibility/blink_ax_tree_source.h
[BrowserAccessibility]: https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility.h
[BrowserAccessibilityDelegate]: https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility_manager.h?sq=package:chromium&l=64
[BrowserAccessibilityManager]: https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility_manager.h
-[LayoutObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutObject.h
+[LayoutObject]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_object.h
[NativeViewAccessibility]: https://cs.chromium.org/chromium/src/ui/views/accessibility/native_view_accessibility.h
-[Node]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Node.h
+[Node]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/Node.h
[RenderAccessibilityImpl]: https://cs.chromium.org/chromium/src/content/renderer/accessibility/render_accessibility_impl.h
[RenderFrameHostImpl]: https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.h
[ui::AXNodeData]: https://cs.chromium.org/chromium/src/ui/accessibility/ax_node_data.h
-[WebAXObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/public/web/WebAXObject.h
+[WebAXObject]: https://cs.chromium.org/chromium/src/third_party/blink/public/web/web_ax_object.h
[automation API]: https://cs.chromium.org/chromium/src/chrome/renderer/resources/extensions/automation
[automation.idl]: https://cs.chromium.org/chromium/src/chrome/common/extensions/api/automation.idl
[ax_enums.idl]: https://cs.chromium.org/chromium/src/ui/accessibility/ax_enums.idl
diff --git a/docs/chromoting_android_hacking.md b/docs/chromoting_android_hacking.md
index fa3b5fdbd78bd3..44a9c8891ce257 100644
--- a/docs/chromoting_android_hacking.md
+++ b/docs/chromoting_android_hacking.md
@@ -79,8 +79,8 @@ display log messages to the `LogCat` pane.
-
-
+
+
diff --git a/docs/how_to_add_your_feature_flag.md b/docs/how_to_add_your_feature_flag.md
index 5707e686f58faa..c46d165067a729 100644
--- a/docs/how_to_add_your_feature_flag.md
+++ b/docs/how_to_add_your_feature_flag.md
@@ -22,11 +22,11 @@ to see
[[1](https://chromium-review.googlesource.com/c/554510/8/content/common/service_worker/service_worker_utils.cc#153)]
3. how to wire the base::Feature to WebRuntimeFeatures
[[1](https://chromium-review.googlesource.com/c/554510/8/content/child/runtime_features.cc)]
-[[2](https://chromium-review.googlesource.com/c/554510/8/third_party/WebKit/public/platform/WebRuntimeFeatures.h)]
-[[3](https://chromium-review.googlesource.com/c/554510/third_party/WebKit/Source/platform/exported/WebRuntimeFeatures.cpp)]
-[[4](https://chromium-review.googlesource.com/c/554510/8/third_party/WebKit/Source/platform/runtime_enabled_features.json5)]
+[[2](https://chromium-review.googlesource.com/c/554510/8/third_party/blink/public/platform/web_runtime_features.h)]
+[[3](https://chromium-review.googlesource.com/c/554510/third_party/blink/Source/platform/exported/web_runtime_features.cc)]
+[[4](https://chromium-review.googlesource.com/c/554510/8/third_party/blink/renderer/platform/runtime_enabled_features.json5)]
4. how to use it in blink
-[[1](https://chromium-review.googlesource.com/c/554510/8/third_party/WebKit/Source/core/workers/WorkerThread.cpp)]
+[[1](https://chromium-review.googlesource.com/c/554510/8/third_party/blnk/renderere/core/workers/worker_thread.cc)]
Also, this patch added a virtual test for running layout tests with the flag.
When you add a flag, you can consider to use that.
diff --git a/docs/memory-infra/README.md b/docs/memory-infra/README.md
index e0aa5758fd1603..84593a8b2bd450 100644
--- a/docs/memory-infra/README.md
+++ b/docs/memory-infra/README.md
@@ -91,7 +91,7 @@ and it is discounted from malloc and the blue columns.
-[oilpan]: /third_party/WebKit/Source/platform/heap/BlinkGCDesign.md
+[oilpan]: /third_party/blink/renderer/platform/heap/BlinkGCDesign.md
[discardable]:base/memory/discardable_memory.h
[cc-memory]: probe-cc.md
[gpu-memory]: probe-gpu.md
diff --git a/docs/origin_trials_integration.md b/docs/origin_trials_integration.md
index f5c1fb5f4b12f9..47f6f20dc78cd9 100644
--- a/docs/origin_trials_integration.md
+++ b/docs/origin_trials_integration.md
@@ -134,7 +134,7 @@ as tests for script-added tokens. For examples, refer to the existing tests in
[chrome_origin_trial_policy.cc]: /chrome/common/origin_trials/chrome_origin_trial_policy.cc
[generate_token.py]: /tools/origin_trials/generate_token.py
[Developer Guide]: https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md
-[OriginTrialEnabled]: /third_party/WebKit/Source/bindings/IDLExtendedAttributes.md#_OriginTrialEnabled_i_m_a_c_
+[OriginTrialEnabled]: /third_party/blink/renderer/bindings/IDLExtendedAttributes.md#_OriginTrialEnabled_i_m_a_c_
[origin_trials/webexposed]: /third_party/WebKit/LayoutTests/http/tests/origin_trials/webexposed/
-[runtime\_enabled\_features.json5]: /third_party/WebKit/Source/platform/runtime_enabled_features.json5
+[runtime\_enabled\_features.json5]: /third_party/blink/renderer/platform/runtime_enabled_features.json5
[trial_token_unittest.cc]: /content/common/origin_trials/trial_token_unittest.cc
diff --git a/docs/testing/writing_layout_tests.md b/docs/testing/writing_layout_tests.md
index d8e6f8ee112fcb..a000b913e7fb71 100644
--- a/docs/testing/writing_layout_tests.md
+++ b/docs/testing/writing_layout_tests.md
@@ -21,7 +21,7 @@ Layout tests should be used to accomplish one of the following goals:
get better. This is very much in line with our goal to move the Web forward.
2. When a Blink feature cannot be tested using the tools provided by WPT, and
cannot be easily covered by
- [C++ unit tests](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/tests/?q=webframetest&sq=package:chromium&type=cs),
+ [C++ unit tests](https://cs.chromium.org/chromium/src/third_party/blink/renderer/web/tests/?q=webframetest&sq=package:chromium&type=cs),
the feature must be covered by layout tests, to avoid unexpected regressions.
These tests will use Blink-specific testing APIs that are only available in
[content_shell](./layout_tests_in_content_shell.md).
diff --git a/mojo/README.md b/mojo/README.md
index 201690cdda78ea..11b0df01455750 100644
--- a/mojo/README.md
+++ b/mojo/README.md
@@ -67,7 +67,7 @@ wrapping and unwrapping helpers, common handle operations, and utilities for
more easily watching handle state changes.
### JavaScript
-The [**JavaScript System API**](/third_party/WebKit/Source/core/mojo) exposes
+The [**JavaScript System API**](/third_party/blink/renderer/core/mojo) exposes
the Mojo primitives to JavaScript, covering all basic functionality of the
low-level C API.
diff --git a/services/device/generic_sensor/README.md b/services/device/generic_sensor/README.md
index 7be265b3f4b70e..e8e31c7a9e01bc 100644
--- a/services/device/generic_sensor/README.md
+++ b/services/device/generic_sensor/README.md
@@ -9,7 +9,7 @@ Sensors Mojo interfaces are defined in the `services/device/public/mojom` subdir
### [Generic Sensors](https://www.w3.org/TR/generic-sensor/)
-The Generic Sensors API is implemented in `third_party/WebKit/Source/modules/sensor` and exposes the following sensor types as JavaScript objects:
+The Generic Sensors API is implemented in `third_party/blink/renderer/modules/sensor` and exposes the following sensor types as JavaScript objects:
* [AbsoluteOrientationSensor] → ABSOLUTE_ORIENTATION_QUATERNION
* [Accelerometer] → ACCELEROMETER
@@ -19,17 +19,17 @@ The Generic Sensors API is implemented in `third_party/WebKit/Source/modules/sen
* [Magnetometer] → MAGNETOMETER
* [RelativeOrientationSensor] → RELATIVE_ORIENTATION_QUATERNION
-[AbsoluteOrientationSensor]: ../../../third_party/WebKit/Source/modules/sensor/AbsoluteOrientationSensor.idl
-[Accelerometer]: ../../../third_party/WebKit/Source/modules/sensor/Accelerometer.idl
-[AmbientLightSensor]: ../../../third_party/WebKit/Source/modules/sensor/AmbientLightSensor.idl
-[Gyroscope]: ../../../third_party/WebKit/Source/modules/sensor/Gyroscope.idl
-[LinearAccelerationSensor]: ../../../third_party/WebKit/Source/modules/sensor/LinearAccelerationSensor.idl
-[Magnetometer]: ../../../third_party/WebKit/Source/modules/sensor/Magnetometer.idl
-[RelativeOrientationSensor]: ../../../third_party/WebKit/Source/modules/sensor/RelativeOrientationSensor.idl
+[AbsoluteOrientationSensor]: ../../../third_party/blink/renderer/modules/sensor/absolute_orientation_sensor.idl
+[Accelerometer]: ../../../third_party/blink/renderer/modules/sensor/accelerometer.idl
+[AmbientLightSensor]: ../../../third_party/blink/renderer/modules/sensor/ambient_light_sensor.idl
+[Gyroscope]: ../../../third_party/blink/renderer/modules/sensor/gyroscope.idl
+[LinearAccelerationSensor]: ../../../third_party/blink/renderer/modules/sensor/linear_acceleration_sensor.idl
+[Magnetometer]: ../../../third_party/blink/renderer/modules/sensor/magnetometer.idl
+[RelativeOrientationSensor]: ../../../third_party/blink/renderer/modules/sensor/relative_orientation_sensor.idl
### [DeviceOrientation Events](https://www.w3.org/TR/orientation-event/)
-The DeviceOrientation Events API is implemented in `third_party/WebKit/Source/modules/device_orientation` and exposes two events based on the following sensors:
+The DeviceOrientation Events API is implemented in `third_party/blink/renderer/modules/device_orientation` and exposes two events based on the following sensors:
* [DeviceMotionEvent]
* ACCELEROMETER: populates the `accelerationIncludingGravity` field
@@ -39,8 +39,8 @@ The DeviceOrientation Events API is implemented in `third_party/WebKit/Source/mo
* ABSOLUTE_ORIENTATION_EULER_ANGLES (when a listener for the `'deviceorientationabsolute'` event is added)
* RELATIVE_ORIENTATION_EULER_ANGLES (when a listener for the `'deviceorientation'` event is added)
-[DeviceMotionEvent]: ../../../third_party/WebKit/Source/modules/device_orientation/DeviceMotionEvent.idl
-[DeviceOrientationEvent]: ../../../third_party/WebKit/Source/modules/device_orientation/DeviceOrientationEvent.idl
+[DeviceMotionEvent]: ../../../third_party/blink/renderer/modules/device_orientation/device_motion_event.idl
+[DeviceOrientationEvent]: ../../../third_party/blink/renderer/modules/device_orientation/device_orientation_event.idl
The content renderer layer is located in `content/renderer/device_sensors`.
diff --git a/third_party/blink/common/README.md b/third_party/blink/common/README.md
index 8284a1905547c3..8dadb84ff2761a 100644
--- a/third_party/blink/common/README.md
+++ b/third_party/blink/common/README.md
@@ -3,24 +3,19 @@
This directory contains the common Web Platform stuff that needs to be shared
by renderer-side and browser-side code.
-Things that live in `third_party/WebKit` can directly depend on this directory,
-while the code outside the WebKit directory (e.g. `//content` and `//chrome`)
+Things that live in `third_party/blink` can directly depend on this directory,
+while the code outside the Blink directory (e.g. `//content` and `//chrome`)
can only depend on the common stuff via the public headers exposed in
-`WebKit/public/common`.
+`blink/public/common`.
Anything in this directory should **NOT** depend on the non-common stuff
-in the WebKit directory. See `DEPS` and `BUILD.gn` files for more details.
+in the Blink directory. See `DEPS` and `BUILD.gn` files for more details.
Code in this directory would normally use `blink` namespace.
-Unlike other directories in WebKit, code in this directory should:
+Unlike other directories in Blink, code in this directory should:
* Use Chromium's common types (e.g. //base ones) rather than Blink's ones
(e.g. WTF types)
-* Use underscore_separated_file_names.cc style rather than CamelCase.cpp.
-
* Follow [Chromium's common coding style guide](https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md)
-
-* Use full-path from src/ for includes (e.g. `third_party/WebKit/common/foo.h`
- rather than `common/foo.h`).
diff --git a/third_party/blink/common/feature_policy/README.md b/third_party/blink/common/feature_policy/README.md
index 684c9471f14d25..b5f40be0394a51 100644
--- a/third_party/blink/common/feature_policy/README.md
+++ b/third_party/blink/common/feature_policy/README.md
@@ -4,7 +4,7 @@
Feature policy (see [spec](https://wicg.github.io/feature-policy/)) is a
mechanism that allows developers to selectively enable and disable various
[browser features and
-APIs](https://cs.chromium.org/chromium/src/third_party/WebKit/public/mojom/feature_policy/feature_policy.mojom)
+APIs](https://cs.chromium.org/chromium/src/third_party/blink/public/mojom/feature_policy/feature_policy.mojom)
(e.g, "vibrate", "fullscreen", "usb", etc.). A feature policy can be defined
via a HTTP header and/or an iframe "allow" attribute.
@@ -51,17 +51,17 @@ policy is undetermined, consider shipping the feature behind a flag (i.e.,
##### Define new feature
1. Feature policy features are defined in
-`third_party/WebKit/public/common/feature_policy/feature_policy_feature.h`. Add the new feature
+`third_party/blink/public/common/feature_policy/feature_policy_feature.h`. Add the new feature
enum with a brief decription about what the feature does in the comment, right
above `LAST_FEATURE`
2. Append the new feature enum with a brief description as well in
-`third_party/WebKit/public/mojom/feature_policy/feature_policy.mojom`
+`third_party/blink/public/mojom/feature_policy/feature_policy.mojom`
-3. Update `third_party/WebKit/public/mojom/feature_policy/feature_policy.mojom_traits.h`
+3. Update `third_party/blink/public/mojom/feature_policy/feature_policy.mojom_traits.h`
to include the new feature
-4. Update `third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp`:
+4. Update `third_party/blink/renderer/platform/feature_policy/feature_policy.cc`:
Add your `("feature-name", FeatureEnumValue)` mapping to
`GetDefaultFeatureNameMap()` (note: "feature-name" is the string web
developers will be using to define the policy in the HTTP header and iframe
diff --git a/third_party/blink/renderer/SpecMapping.md b/third_party/blink/renderer/SpecMapping.md
index 5702433a8265f0..8abae0f9717d01 100644
--- a/third_party/blink/renderer/SpecMapping.md
+++ b/third_party/blink/renderer/SpecMapping.md
@@ -15,8 +15,8 @@ Concepts found in the [HTML spec](https://html.spec.whatwg.org/).
A browsing context corresponds to the [Frame] interface where the main
implementation is [LocalFrame].
-[Frame]: https://cs.chromium.org/src/third_party/WebKit/Source/core/frame/Frame.h
-[LocalFrame]: https://cs.chromium.org/src/third_party/WebKit/Source/core/frame/LocalFrame.h
+[Frame]: https://cs.chromium.org/src/third_party/blink/renderer/core/frame/frame.h
+[LocalFrame]: https://cs.chromium.org/src/third_party/blink/renderer/core/frame/local_frame.h
### [origins](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin)
@@ -24,7 +24,7 @@ An origin corresponds to the [SecurityOrigin]. You can test for [same-origin]
using `SecurityOrigin::canAccess` and for [same-origin domain] using
`SecurityOrigin::isSameSchemeHostPort`.
-[SecurityOrigin]: https://cs.chromium.org/src/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.h
+[SecurityOrigin]: https://cs.chromium.org/src/third_party/blink/renderer/platform/weborigin/security_origin.h
[same-origin]: https://html.spec.whatwg.org/multipage/browsers.html#same-origin
[same-origin domain]: https://html.spec.whatwg.org/multipage/browsers.html#same-origin-domain
@@ -34,8 +34,8 @@ using `SecurityOrigin::canAccess` and for [same-origin domain] using
A Window object corresponds to the [DOMWindow] interface where the main
implementation is [LocalDOMWindow].
-[DOMWindow]: https://cs.chromium.org/src/third_party/WebKit/Source/core/frame/DOMWindow.h
-[LocalDOMWindow]: https://cs.chromium.org/src/third_party/WebKit/Source/core/frame/LocalDOMWindow.h
+[DOMWindow]: https://cs.chromium.org/src/third_party/blink/renderer/core/frame/dom_window.h
+[LocalDOMWindow]: https://cs.chromium.org/src/third_party/blink/renderer/core/frame/local_dom_window.h
### [WindowProxy](https://html.spec.whatwg.org/#windowproxy)
@@ -52,14 +52,14 @@ are supported for different use cases.
The main element's sources are in [HTMLCanvasElement]. Contexts are implemented
via modules. The top-level module is [HTMLCanvasElementModule].
-[HTMLCanvasElement]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
-[HTMLCanvasElementModule]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/canvas/HTMLCanvasElementModule.h
+[HTMLCanvasElement]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/html_canvas_element.h
+[HTMLCanvasElementModule]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/canvas/html_canvas_element_module.h
The [2D canvas context] is implemented in [modules/canvas2d].
[2D canvas context]: https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2d
-[modules/canvas2d]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/canvas2d/
+[modules/canvas2d]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/canvas2d/
The [WebGL 1.0] and [WebGL 2.0] contexts ([WebGL Github repo]) are implemented
@@ -68,4 +68,4 @@ in [modules/webgl].
[WebGL 1.0]: https://www.khronos.org/registry/webgl/specs/latest/1.0/
[WebGL 2.0]: https://www.khronos.org/registry/webgl/specs/latest/2.0/
[WebGL Github repo]: https://github.com/KhronosGroup/WebGL
-[modules/webgl]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/webgl/
+[modules/webgl]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/
diff --git a/third_party/blink/renderer/bindings/IDLCompiler.md b/third_party/blink/renderer/bindings/IDLCompiler.md
index 7ed1094185f5b3..e72063a73b0725 100644
--- a/third_party/blink/renderer/bindings/IDLCompiler.md
+++ b/third_party/blink/renderer/bindings/IDLCompiler.md
@@ -9,7 +9,7 @@ Users of the IDL compiler consist of:
* Other bindings generators (who want to compile Blink IDL files), which use the front end and optionally parts of the top-level compiler and build scripts.
* Other IDL use: Web IDL is a convenient format for specifying JavaScript interfaces, and the front end can be used for reading these files, most simply using the IR object (`IdlDefinitions`).
-The compiler is in [Source/bindings/scripts](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/), and bindings are generated as part of the build (see [IDL build](https://sites.google.com/a/chromium.org/dev/developers/design-documents/idl-build)). The top-level file [idl_compiler.py](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/idl_compiler.py), can be invoked directly (if you want to compile a single file), or via [Tools/Scripts/run-bindings-tests](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Tools/Scripts/run-bindings-tests). The rest of this document describes design, implementation, and use.
+The compiler is in [Source/bindings/scripts](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/), and bindings are generated as part of the build (see [IDL build](https://sites.google.com/a/chromium.org/dev/developers/design-documents/idl-build)). The top-level file [idl_compiler.py](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/idl_compiler.py), can be invoked directly (if you want to compile a single file), or via [Tools/Scripts/run-bindings-tests](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Tools/Scripts/run-bindings-tests). The rest of this document describes design, implementation, and use.
## Overall structure
The compiler is factored into a pipeline, and the steps further divided into separate Python modules. While there are a number of components, each is simple and well-defined, and generally only one or two must be considered at a time.
@@ -59,11 +59,11 @@ However, the back end ([code generator](http://en.wikipedia.org/wiki/Code_genera
Further, the input language is declarative (the 'D' in IDL), so no optimizations of input code are necessary (there is no _middle end_): it's just filling in a template. The back end is itself divided into the templates themselves, and the Python code that fills in the templates (produces the _context_). There is also no separate [_semantic analysis_](http://en.wikipedia.org/wiki/Semantic_analysis_(compilers)) step, except for validation of extended attributes (see below): the code generator assumes types are valid, and errors show up when the resulting C++ code fails to compile. This avoids the complexity and time cost of either a separate validation step, or of type-checking in the code generator, at the cost of typos showing up in compile failures instead of at IDL compile time. Notably, there is no type checking or name binding, since identifiers are assumed to refer to Web IDL interfaces (C++ classes) and the Web IDL namespace is global, and there is no assignment, since Web IDL is declarative.
## Code
-Code-wise, the top-level file [`idl_compiler.py`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/idl_compiler.py) imports two modules: [`idl_reader`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/idl_reader.py) for the front end, [`code_generator_v8`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/code_generator_v8.py) for the back end. Each of these is used to create an object (`IdlReader` and `CodeGeneratorV8`), which handles the library initialization (PLY or Jinja, which are slow, and thus reused if running multiple times during one run) and global information. The objects are then called one time each, for the IDL --> IR and IR --> C++ steps, respectively. By contrast, `run-bindings-tests` creates these objects as well, then calls them multiple times, once for each test file. Note that in the actual build, compilation is parallelized, which is why only one file is compiled per process, and there is a pre-caching step which significantly speeds up library initialization.
+Code-wise, the top-level file [`idl_compiler.py`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/idl_compiler.py) imports two modules: [`idl_reader`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/idl_reader.py) for the front end, [`code_generator_v8`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/code_generator_v8.py) for the back end. Each of these is used to create an object (`IdlReader` and `CodeGeneratorV8`), which handles the library initialization (PLY or Jinja, which are slow, and thus reused if running multiple times during one run) and global information. The objects are then called one time each, for the IDL --> IR and IR --> C++ steps, respectively. By contrast, `run-bindings-tests` creates these objects as well, then calls them multiple times, once for each test file. Note that in the actual build, compilation is parallelized, which is why only one file is compiled per process, and there is a pre-caching step which significantly speeds up library initialization.
The code is mostly functional, except for a few module-level variables in the code generator (discussed below) for simplicity, and some objects used for initialization.
-The main classes are as follows, with the module in which they are defined. Note that the relations are primarily composition, with inheritance significantly used for the Blink-specific lexer and parser. `IdlCompiler, IdlReader,` and `CodeGeneratorV8` are expected to be used as singletons, and are just classes for initialization (avoids expensive re-initialization, and interface-wise separates initialization from execution). `IdlDefinitions` contains objects of a few other classes (for more minor data), and there is a bit of complex OO code in [`idl_definitions`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/idl_definitions.py) to simplify [typedef](http://heycam.github.io/webidl/#idl-typedefs) resolution.
+The main classes are as follows, with the module in which they are defined. Note that the relations are primarily composition, with inheritance significantly used for the Blink-specific lexer and parser. `IdlCompiler, IdlReader,` and `CodeGeneratorV8` are expected to be used as singletons, and are just classes for initialization (avoids expensive re-initialization, and interface-wise separates initialization from execution). `IdlDefinitions` contains objects of a few other classes (for more minor data), and there is a bit of complex OO code in [`idl_definitions`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/idl_definitions.py) to simplify [typedef](http://heycam.github.io/webidl/#idl-typedefs) resolution.
```
IdlCompiler :: idl_compiler
@@ -91,15 +91,15 @@ There are two other steps:
* extended attribute validation
* dependency resolution
-The top-level module for the front end is [`idl_reader`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/idl_reader.py). This implements a class, `IdlReader`, whose constructor also constructs a lexer, parser, validator, and resolver. `IdlReader` implements a method to construct an IR object (`IdlDefinitions`) from an IDL filename. Thus to convert IDL to IR one instantiates a reader, then call its method to read an IDL file.
+The top-level module for the front end is [`idl_reader`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/idl_reader.py). This implements a class, `IdlReader`, whose constructor also constructs a lexer, parser, validator, and resolver. `IdlReader` implements a method to construct an IR object (`IdlDefinitions`) from an IDL filename. Thus to convert IDL to IR one instantiates a reader, then call its method to read an IDL file.
The lexer-parser uses [PLY (Python Lex-Yacc)](http://www.dabeaz.com/ply/). In fact, the lexer and parser for the Blink IDL dialect of Web IDL derive from a base lexer and base parser for standard Web IDL (in [tools/idl_parser](https://code.google.com/p/chromium/codesearch#chromium/src/tools/idl_parser)), and thus only need to include deviations from the standard. The lexical syntax of Blink IDL is standard (though the base lexer is slightly non-standard), so the Blink IDL lexer is very small and slated for removal (Bug [345137](https://code.google.com/p/chromium/issues/detail?id=345137)). The phrase syntax is slightly non-standard (primarily in extended attributes) and expected to stay this way, as extended attributes are implementation-dependent and the deviations are useful (see [Blink IDL: syntax](http://www.chromium.org/blink/webidl#TOC-Syntax)). We thus say that the base lexer/parser + Blink lexer/parser form 1 lexer and 1.1 parser (base + derived).
The base lexer class, defined in [`idl_lexer`](https://code.google.com/p/chromium/codesearch#chromium/src/tools/idl_parser/idl_lexer.py), is straightforward and short: it is just a list of regular expressions and keywords, wrapped in a class, `IDLLexer`; a lexer (object) itself is an instance of this class. There is some minor complexity with error handling (correct line count) and methods to assist with derived classes, but it's quite simple. The derived lexer class is very simple: it's a class, `BlinkIDLLexer`, which derives from the base class. The only complexity is adding a method to remove a token class from the base class, and to remove comments (base lexer is non-standard here: standard lexer does not produce `COMMENT` tokens).
-The base parser class, defined in [`idl_parser`](https://code.google.com/p/chromium/codesearch#chromium/src/tools/idl_parser/idl_parser.py), is considerably longer, but consists almost entirely of production rules in (a form of) [BNF](http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form), together with yacc _actions_ that build an [abstract syntax tree](http://en.wikipedia.org/wiki/Abstract_syntax_tree) (AST, syntax tree). Recall that yacc _traverses_ the [concrete syntax tree](http://en.wikipedia.org/wiki/Concrete_syntax_tree) (CST, parse tree) and can take whatever actions it chooses; in this case it generates an AST, though it could also generate the IR directly. See [`blink_idl_parser`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/blink_idl_parser.py) for a detailed explanation of the PLY yacc syntax and `IDLParser` methods used to construct the AST. The grammar is directly from the [Web IDL grammar](http://heycam.github.io/webidl/#idl-grammar), which is an [LL(1) grammar](http://en.wikipedia.org/wiki/LL_grammar); the Blink IDL rules are exactly the deviations from the standard grammar, or overrides to irregularities in the base parser. A parser object is an instance of a class, `IDLParser`, from which `BlinkIDLParser` is derived. The parser constructor takes a lexer as an argument, and one passes the corresponding lexer.
+The base parser class, defined in [`idl_parser`](https://code.google.com/p/chromium/codesearch#chromium/src/tools/idl_parser/idl_parser.py), is considerably longer, but consists almost entirely of production rules in (a form of) [BNF](http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form), together with yacc _actions_ that build an [abstract syntax tree](http://en.wikipedia.org/wiki/Abstract_syntax_tree) (AST, syntax tree). Recall that yacc _traverses_ the [concrete syntax tree](http://en.wikipedia.org/wiki/Concrete_syntax_tree) (CST, parse tree) and can take whatever actions it chooses; in this case it generates an AST, though it could also generate the IR directly. See [`blink_idl_parser`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/blink_idl_parser.py) for a detailed explanation of the PLY yacc syntax and `IDLParser` methods used to construct the AST. The grammar is directly from the [Web IDL grammar](http://heycam.github.io/webidl/#idl-grammar), which is an [LL(1) grammar](http://en.wikipedia.org/wiki/LL_grammar); the Blink IDL rules are exactly the deviations from the standard grammar, or overrides to irregularities in the base parser. A parser object is an instance of a class, `IDLParser`, from which `BlinkIDLParser` is derived. The parser constructor takes a lexer as an argument, and one passes the corresponding lexer.
-The definitions classes, defined in [idl_definitions](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/idl_definitions.py), primarily consist of constructors, which take the AST and generate an intermediate representation (IR), in this case an object of type `IdlDefinitions` and contained objects for individual definitions and definition's members.
+The definitions classes, defined in [idl_definitions](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/idl_definitions.py), primarily consist of constructors, which take the AST and generate an intermediate representation (IR), in this case an object of type `IdlDefinitions` and contained objects for individual definitions and definition's members.
The classes are as follows (mostly composition, one case of inheritance); a few internal-use only classes are not shown:
@@ -120,7 +120,7 @@ After reading an IDL file (producing an IR), the reader has two optional additio
### Extended attribute validation
The front end largely does not do [semantic analysis](http://en.wikipedia.org/wiki/Semantic_analysis_%28compilers%29), as semantic errors (primarily name errors) are largely caught by the build visibly failing, either during the IDL compile or during the C++ compile (name lookup errors). Notably, there is no symbol table or name binding in the front end: each name is simply looked up on use (e.g., type names), or passed through to the output (e.g., attribute names), and catch errors by the lookup failing or the generated code failing to compile, respectively.
-However, extended attributes are validated, both the keys and values, based on the list in [`IDLExtendedAttributes.txt`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/IDLExtendedAttributes.txt). This is done because invalid extended attributes are _ignored_ by the compiler, specifically the code generator, and thus errors are easy to miss. The Python code checks for specific extended attributes, so errors just result in the attribute not being found; for example, writing `[EnforecRange]` for `[EnforceRange]` would otherwise silently result in the range not being enforced. This is not perfect: extended attributes may be valid but used incorrectly (e.g., specified on an attribute when they only apply to methods), which is not caught; this is however a minor problem.
+However, extended attributes are validated, both the keys and values, based on the list in [`IDLExtendedAttributes.txt`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/IDLExtendedAttributes.txt). This is done because invalid extended attributes are _ignored_ by the compiler, specifically the code generator, and thus errors are easy to miss. The Python code checks for specific extended attributes, so errors just result in the attribute not being found; for example, writing `[EnforecRange]` for `[EnforceRange]` would otherwise silently result in the range not being enforced. This is not perfect: extended attributes may be valid but used incorrectly (e.g., specified on an attribute when they only apply to methods), which is not caught; this is however a minor problem.
This is done in the front end since that is the proper place for semantic analysis, and simplifies the code generator.
@@ -141,7 +141,7 @@ The subtleties are:
Also, note that the compiler currently does not do significant type introspection of referenced interfaces: it mostly just uses certain global information about the interface (is it a callback interface?, `[ImplementedAs],` etc.). The only significant use of type introspection is in `[PutForwards],` where generating the code for an attribute with `[PutForwards]` requires looking up the referenced attribute in another interface. Type introspection may increase in future, to simplify complex cases and reduce hard-coding, but for now is in very limited use.
## Back end (code generator)
-The back end (code generator, CG) is where the bulk of the complexity is. The structure is simple: the Python V8 CG modules (`v8_*`) generate a dictionary called the **context**, which is passed to Jinja, which uses this dict to fill in the appropriate templates ([bindings/templates](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/templates/)/*.{cpp,h}). The modules correspond to the class structure in IR, with the following exceptions:
+The back end (code generator, CG) is where the bulk of the complexity is. The structure is simple: the Python V8 CG modules (`v8_*`) generate a dictionary called the **context**, which is passed to Jinja, which uses this dict to fill in the appropriate templates ([bindings/templates](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/templates/)/*.{cpp,h}). The modules correspond to the class structure in IR, with the following exceptions:
* the CG uses “method” where the front end uses “operation” (the term in the spec), since “method” is a more standard term;
* constants are included in `v8_interface`, because very simple; and
* arguments are included in `v8_methods`, because they are closely related to methods.
@@ -165,12 +165,12 @@ The CG modules each have a top-level `*_context` function_,_ which takes an IR o
Note that the context is nested – the context for an interfaces contains a list of contexts for the members: attributes, constants, and methods. The context for a given member is used throughout the corresponding template, generally to generate several methods; e.g., in `attributes.cpp` there are macros for getter, getter callback, setter, and setter callback, which are called from a loop in `interface_base.cpp`. The context for members is _also_ used at the overall interface level, notably for DOM configuration.
## Style
-[`v8_attributes.py`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/v8_attributes.py) (Python) and [`attributes.cpp`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/templates/attributes.cpp) (Jinja) are a good guide to style: the getter and setter methods themselves are quite complex, while the callbacks are simple.
+[`v8_attributes.py`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/v8_attributes.py) (Python) and [`attributes.cpp`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/templates/attributes.cpp) (Jinja) are a good guide to style: the getter and setter methods themselves are quite complex, while the callbacks are simple.
See [Jinja: Style](https://sites.google.com/a/chromium.org/dev/developers/jinja#TOC-Style) for general Jinja style tips; below is bindings generator specific guidance.
### Jinja
-If nesting macros (so macros that call macros), use top-down order: top-level macro, followed by macros it calls. This is most notable in [`methods.cpp`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/templates/methods.cpp), where generating a method also requires generating code for the arguments, which comes after.
+If nesting macros (so macros that call macros), use top-down order: top-level macro, followed by macros it calls. This is most notable in [`methods.cpp`](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/templates/methods.cpp), where generating a method also requires generating code for the arguments, which comes after.
### Python
Assertions should _not_ be used for validating input, and this includes IDL files: if an IDL file is invalid (e.g., it uses an extended attribute improperly), raise an exception explicitly. Assertions can be used for validating internal logic, but in practice this is rare in the code generator; see [Using Assertions Effectively](https://wiki.python.org/moin/UsingAssertionsEffectively).
@@ -266,7 +266,7 @@ Potential future improvements (without substantial reengineering) would primaril
* [Jinja performance](http://www.chromium.org/developers/jinja#TOC-Performance)
## References
-* [Source/bindings/scripts](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/): the code
+* [Source/bindings/scripts](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/): the code
* [Issue 239771: Rewrite the IDL compiler in Python](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/s1xTE428OAs): tracking bug for rewrite (2013/2014)
* [IDL compiler (V8 bindings generator) switched to Python](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/s1xTE428OAs): wrap-up email for rewrite (Feb 2014)
* [followup](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5FSUhiugWsE) about front end
diff --git a/third_party/blink/renderer/bindings/IDLExtendedAttributes.md b/third_party/blink/renderer/bindings/IDLExtendedAttributes.md
index d4324d60f1b57f..f748970153ad43 100644
--- a/third_party/blink/renderer/bindings/IDLExtendedAttributes.md
+++ b/third_party/blink/renderer/bindings/IDLExtendedAttributes.md
@@ -6,7 +6,7 @@
The main interest in extended attributes are their _semantics_: Blink implements many more extended attributes than the Web IDL standard, to specify various behavior.
-The authoritative list of allowed extended attributes and values is [bindings/IDLExtendedAttributes.txt](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/IDLExtendedAttributes.txt). This is complete but not necessarily precise (there may be unused extended attributes or values), since validation is run on build, but coverage isn't checked.
+The authoritative list of allowed extended attributes and values is [bindings/IDLExtendedAttributes.txt](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/IDLExtendedAttributes.txt). This is complete but not necessarily precise (there may be unused extended attributes or values), since validation is run on build, but coverage isn't checked.
Syntactically, Blink IDL extended attributes differ from standard Web IDL extended attributes in a few ways:
@@ -59,7 +59,7 @@ Extended attributes mostly work normally on overloaded methods, affecting only t
While `[DeprecateAs]`, `[MeasureAs]` only affect callback for non-overloaded methods, the logging code is instead put in the method itself for overloaded methods, so these can be placed on the method to log in question.
***
-Extended attributes that affect the callback must be on the _last_ overloaded method, though it is safest to put them on all the overloaded methods, for consistency (and in case they are rearranged or deleted). The source is [bindings/templates/methods.cpp](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/templates/methods.cpp), and currently there are no extended attribute that affect the callback (even for overloaded methods).
+Extended attributes that affect the callback must be on the _last_ overloaded method, though it is safest to put them on all the overloaded methods, for consistency (and in case they are rearranged or deleted). The source is [bindings/templates/methods.cpp](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/templates/methods.cpp), and currently there are no extended attribute that affect the callback (even for overloaded methods).
### Special operations (methods)
@@ -128,7 +128,7 @@ Extended attributes on members of an implemented interface work as normal. Howev
### Inheritance
-Extended attributes are generally not inherited: only extended attributes on the interface itself are consulted. However, there are a handful of extended attributes that are inherited (applying them to an ancestor interface applies them to the descendants). These are extended attributes that affect memory management, and currently consists of `[ActiveScriptWrappable]`; the up-to-date list is [compute_dependencies.INHERITED_EXTENDED_ATTRIBUTES](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/scripts/compute_dependencies.py&q=INHERITED_EXTENDED_ATTRIBUTES).
+Extended attributes are generally not inherited: only extended attributes on the interface itself are consulted. However, there are a handful of extended attributes that are inherited (applying them to an ancestor interface applies them to the descendants). These are extended attributes that affect memory management, and currently consists of `[ActiveScriptWrappable]`; the up-to-date list is [compute_dependencies.INHERITED_EXTENDED_ATTRIBUTES](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/bindings/scripts/compute_dependencies.py&q=INHERITED_EXTENDED_ATTRIBUTES).
## Standard Web IDL Extended Attributes
@@ -902,7 +902,7 @@ This attribute is only for Custom Elements V0,
and is superceded by `[CEReactions]` for V1.
***
-If the method/accessor creates elements or modifies DOM nodes in any way, it should be tagged with this extended attribute. Even if you're not a Node, this may apply to you! For example [DOMTokenList.toggle](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/DOMTokenList.idl&l=34) can be reflected in the attribute of its associated element, so it needs to be tagged with CustomElementCallbacks. If the method/accessor only calls something that may modify the DOM (for example, it runs user script as a callback) you don't need to tag your method with `[CustomElementCallbacks]`; that is the responsibility of the binding that actually modifies the DOM. In general over-applying this extended attribute is safe, with one caveat:
+If the method/accessor creates elements or modifies DOM nodes in any way, it should be tagged with this extended attribute. Even if you're not a Node, this may apply to you! For example [DOMTokenList.toggle](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/core/dom/dom_token_list.idl&l=34) can be reflected in the attribute of its associated element, so it needs to be tagged with CustomElementCallbacks. If the method/accessor only calls something that may modify the DOM (for example, it runs user script as a callback) you don't need to tag your method with `[CustomElementCallbacks]`; that is the responsibility of the binding that actually modifies the DOM. In general over-applying this extended attribute is safe, with one caveat:
* This extended attribute MUST NOT be used on members that operate on non-main threads, because the callback delivery scope accesses statics.
* Basically: Don't apply this extended attribute to anything that can be called from a worker.
@@ -947,7 +947,7 @@ Usage: `[DeprecateAs]` can be specified on methods, attributes, and constants.
[DeprecateAs=DeprecatedPrefixedConstant] const short DEPRECATED_PREFIXED_CONSTANT = 1;
```
-The deprecation message show on the console can be specified via the [UseCounter::deprecationMessage](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/UseCounter.cpp&q=UseCounter::deprecationMessage&l=615) method.
+The deprecation message show on the console can be specified via the [UseCounter::deprecationMessage](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/core/frame/use_counter.cc&q=UseCounter::deprecationMessage&l=615) method.
### [DoNotTestNewObject] _(m)_
@@ -961,7 +961,7 @@ Summary: Measures usage of a specific feature via UseCounter.
In order to measure usage of specific features, Chrome submits anonymous statistics through the Histogram recording system for users who opt-in to sharing usage statistics. This extended attribute hooks up a specific feature to this measurement system.
-Usage: `[Measure]` can be specified on interfaces, methods, attributes, and constants. When specified on an interface usage of the constructor will be measured. The generated feature name must be added to [UseCounter::Feature](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/UseCounter.h&q=%22enum%20Feature%22&sq=package:chromium&type=cs&l=61) (in [core/frame/UseCounter.h](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/UseCounter.h)).
+Usage: `[Measure]` can be specified on interfaces, methods, attributes, and constants. When specified on an interface usage of the constructor will be measured. The generated feature name must be added to [UseCounter::Feature](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/core/frame/use_counter.h&q=%22enum%20Feature%22&sq=package:chromium&type=cs&l=61) (in [core/frame/use_counter.h](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/core/frame/use_counter.h)).
```webidl
[Measure] attribute Node interestingAttribute;
@@ -974,7 +974,7 @@ Usage: `[Measure]` can be specified on interfaces, methods, attributes, and cons
Summary: Like `[Measure]`, but the feature name is provided as the extended attribute value.
This is similar to the standard `[DeprecateAs]` extended attribute, but does not display a deprecation warning.
-Usage: `[MeasureAs]` can be specified on interfaces, methods, attributes, and constants. The value must match one of the enumeration values in [UseCounter::Feature](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/UseCounter.h&q=%22enum%20Feature%22&sq=package:chromium&type=cs&l=61) (in [core/frame/UseCounter.h](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/UseCounter.h)).
+Usage: `[MeasureAs]` can be specified on interfaces, methods, attributes, and constants. The value must match one of the enumeration values in [UseCounter::Feature](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/core/frame/use_counter.h&q=%22enum%20Feature%22&sq=package:chromium&type=cs&l=61) (in [core/frame/use_counter.h](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/core/frame/use_counter.h)).
```webidl
[MeasureAs=AttributeWeAreInterestedIn] attribute Node interestingAttribute;
@@ -1005,7 +1005,7 @@ Usage: `[NotEnumerable]` can be specified on methods and attributes
Summary: Like `[RuntimeEnabled]`, it controls at runtime whether bindings are exposed, but uses a different mechanism for enabling experimental features.
-Usage: `[OriginTrialEnabled=FeatureName]`. FeatureName must be included in [runtime\_enabled\_features.json5](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/runtime_enabled_features.json5), and is the same value that would be used with `[RuntimeEnabled]`.
+Usage: `[OriginTrialEnabled=FeatureName]`. FeatureName must be included in [runtime\_enabled\_features.json5](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/platform/runtime_enabled_features.json5), and is the same value that would be used with `[RuntimeEnabled]`.
```webidl
[
@@ -1017,7 +1017,7 @@ When there is an active origin trial for the current execution context, the feat
`[OriginTrialEnabled]` has similar semantics to `[RuntimeEnabled]`, and is intended as a drop-in replacement. For example, `[OriginTrialEnabled]` _cannot_ be applied to arguments, see `[RuntimeEnabled]` for reasoning. The key implementation difference is that `[OriginTrialEnabled]` wraps the generated code with `if (OriginTrials::FeatureNameEnabled(...)) { ...code... }`.
-For more information, see [RuntimeEnabledFeatures](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/runtime_enabled_features.json5) and [OriginTrialContext](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/origin_trials/OriginTrialContext.h).
+For more information, see [RuntimeEnabledFeatures](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/platform/runtime_enabled_features.json5) and [OriginTrialContext](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/core/origin_trials/origin_trial_context.h).
*** note
**FIXME:** Currently, `[OriginTrialEnabled]` can only be applied to interfaces, attributes, and constants. Methods (including those generated by `iterable`, `setlike`, `maplike`, `serializer` and `stringifier`) are not supported. See [Bug 621641](https://crbug.com/621641).
@@ -1208,7 +1208,7 @@ If there is no match, the empty string will be returned. As required by the spec
Summary: `[RuntimeEnabled]` wraps the generated code with `if (RuntimeEnabledFeatures::FeatureNameEnabled) { ...code... }`.
-Usage: `[RuntimeEnabled=FeatureName]`. FeatureName must be included in [runtime\_enabled\_features.json5](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/runtime_enabled_features.json5).
+Usage: `[RuntimeEnabled=FeatureName]`. FeatureName must be included in [runtime\_enabled\_features.json5](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/platform/runtime_enabled_features.json5).
```webidl
[
@@ -1232,7 +1232,7 @@ foo(long x);
[RuntimeEnabled=FeatureName] foo(long x, long y);
```
-For more information, see [RuntimeEnabledFeatures](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/runtime_enabled_features.json5).
+For more information, see [RuntimeEnabledFeatures](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/blink/renderer/platform/runtime_enabled_features.json5).
### [SaveSameObject] _(a)_
diff --git a/third_party/blink/renderer/core/animation/README.md b/third_party/blink/renderer/core/animation/README.md
index 6a2aa7aef821e5..7fb2b0e266ebb5 100644
--- a/third_party/blink/renderer/core/animation/README.md
+++ b/third_party/blink/renderer/core/animation/README.md
@@ -108,12 +108,12 @@ The Blink animation engine interacts with Blink/Chrome in the following ways:
* ### Javascript
- [EffectInput](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/animation/EffectInput.cpp)
+ [EffectInput](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/animation/effect_input.cc)
contains the helper functions that are used to
[process a keyframe argument](https://drafts.csswg.org/web-animations/#processing-a-keyframes-argument)
which can take an argument of either object or array form.
- [PlayStateUpdateScope](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/animation/Animation.h?l=323):
+ [PlayStateUpdateScope](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/animation/animation.h?l=323):
whenever there is a mutation to the animation engine from JS level, this
gets created and the destructor has the logic that handles everything. It
keeps the old and new state of the animation, checks the difference and
@@ -135,7 +135,7 @@ The Blink animation engine interacts with Blink/Chrome in the following ways:
animation without having any effect on the underlying animation or its
listeners.
-[InspectorAnimationAgent]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/inspector/InspectorAnimationAgent.h
+[InspectorAnimationAgent]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/inspector/InspectorAnimationAgent.h
* ### SVG
@@ -360,7 +360,7 @@ about the state.
[extending Test]: https://cs.chromium.org/search/?q=public%5C+testing::Test+file:core%5C/Animation&sq=package:chromium&type=cs
[extending RenderingTest]: https://cs.chromium.org/search/?q=public%5C+RenderingTest+file:core%5C/animation&type=cs
-[enable compositing]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/animation/CompositorAnimationsTest.cpp?type=cs&sq=package:chromium&q=file:core%5C/animation%5C/.*Test%5C.cpp+EnableCompositing
+[enable compositing]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/animation/compositor_animations_test.cc?type=cs&sq=package:chromium&q=file:core%5C/animation%5C/.*Test%5C.cpp+EnableCompositing
## Ongoing work
diff --git a/third_party/blink/renderer/core/css/README.md b/third_party/blink/renderer/core/css/README.md
index ed181b54a8f131..3d264a4e95449d 100644
--- a/third_party/blink/renderer/core/css/README.md
+++ b/third_party/blink/renderer/core/css/README.md
@@ -1,6 +1,6 @@
# CSS
-[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/css/README.md)
+[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/css/README.md)
The `Source/core/css` directory contains the implementation of CSS.
diff --git a/third_party/blink/renderer/core/css/cssom/README.md b/third_party/blink/renderer/core/css/cssom/README.md
index 94a424667d1ef5..688d207c927a73 100644
--- a/third_party/blink/renderer/core/css/cssom/README.md
+++ b/third_party/blink/renderer/core/css/cssom/README.md
@@ -1,6 +1,6 @@
# CSS Typed OM
-[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/css/cssom/README.md)
+[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/css/cssom/README.md)
The `Source/core/css/cssom` directory contains the implementation of [CSS Typed OM](https://drafts.css-houdini.org/css-typed-om).
diff --git a/third_party/blink/renderer/core/css/properties/README.md b/third_party/blink/renderer/core/css/properties/README.md
index 9d1dea8dc3067d..21001b09e4a4c6 100644
--- a/third_party/blink/renderer/core/css/properties/README.md
+++ b/third_party/blink/renderer/core/css/properties/README.md
@@ -47,7 +47,7 @@ Aliases are properties that share most of their logic with another property,
somtimes with the exception of some minor differences in parsing logic due to
legacy reasons. Many aliases are -webit prefixed properties that have since
been implemented without the prefix. Aliases define the alias_for member in
-[CSSProperties.json5](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/CSSProperties.json5)).
+[CSSProperties.json5](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/CSSProperties.json5)).
Alias classes implement a small subset of functions of properties, only those
that do not share an implementation with the resolved property that they are an
@@ -89,18 +89,18 @@ headers are in this directory.
2. Implement the required methods on the property class.
3. If logic is required by multiple property classes you may need to create a
new Utils file. These utils methods are grouped by pipeline function (e.g.
- [CSSParsingUtils](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/properties/CSSParsingUtils.h)).
+ [CSSParsingUtils](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/properties/css_parsing_utils.h)).
4. Add the new property to `core/css/CSSProperties.json5`. Ensure that you
include all the methods implemented on the property in the
'property_methods' flag so that the header file is generated correctly (see
- [CSSProperties.json5](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/CSSProperties.json5)
+ [CSSProperties.json5](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/CSSProperties.json5)
for more details)
5. Add new files to BUILD files
1. Add the new .cpp file to
- [core/css/BUILD.gn](https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/core/css/BUILD.gn)
+ [core/css/BUILD.gn](https://codesearch.chromium.org/chromium/src/third_party/blink/renderer/core/css/BUILD.gn)
in the `blink_core_sources` target's `sources` parameter
2. Add the generated .h file to
- [core/BUILD.gn](https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/core/BUILD.gn)
+ [core/BUILD.gn](https://codesearch.chromium.org/chromium/src/third_party/blink/renderer/core/BUILD.gn)
in the `css_properties` target's `outputs` parameter. This step is often
forgotten and may not immediately caues an error but can cause linking
errors in certain situations.
diff --git a/third_party/blink/renderer/core/css/style-calculation.md b/third_party/blink/renderer/core/css/style-calculation.md
index da9f8ac58547a1..6f13acaa96f636 100644
--- a/third_party/blink/renderer/core/css/style-calculation.md
+++ b/third_party/blink/renderer/core/css/style-calculation.md
@@ -1,4 +1,4 @@
-[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/css/style-calculation.md)
+[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/css/style-calculation.md)
# About this document
@@ -31,13 +31,13 @@ The process of calculating styles for the elements is broken into 3 phases:
A catalogue of the classes involved. Read their class docs.
* [`Element`](https://cs.chromium.org/?q=symbol:%5Eblink::Element$) See also
-[dom/README.md](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/dom/README.md)
+[dom/README.md](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/dom/README.md)
* [`TreeScope`](https://cs.chromium.org/?q=symbol:%5Eblink::TreeScope$)
Represents a tree of elements for a document or shadow root. Gives fast access
to various things inside the tree of elements. Holds a
[`ScopedStyleResolver`](https://cs.chromium.org/?q=symbol:%5Eblink::ScopedStyleResolver$)
for this scope. See
-[dom/README.md](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/dom/README.md#treescope)
+[dom/README.md](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/dom/README.md#treescope)
* [`StyleEngine`](https://cs.chromium.org/?q=symbol:%5Eblink::StyleEngine$)
* [`StyleResolver`](https://cs.chromium.org/?q=symbol:%5Eblink::StyleResolver$)
* [`ScopedStyleResolver`](https://cs.chromium.org/?q=symbol:%5Eblink::ScopedStyleResolver$)
@@ -209,7 +209,7 @@ The tree is traversed in [shadow-including tree
oreder](https://www.w3.org/TR/shadow-dom/#concept-shadow-including-tree-order). There
are 2 recursive paths that can be taken. The simpler one is in the case where
the
-[change](https://chromium.googlesource.com/chromium/src/+/lkcr/third_party/WebKit/Source/core/style/stylerecalc.md)
+[change](https://chromium.googlesource.com/chromium/src/+/lkcr/third_party/blink/renderer/core/style/stylerecalc.md)
being applied is
[`ComputedStyleConstants::kReattach`](https://cs.chromium.org/?q=symbol:%5Eblink::StyleRecalcChange::kReattach$). It
recurses through
@@ -228,13 +228,13 @@ calculation is performed by
# Omissions
* Caching, fast reject,
- [`NthIndexCache`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/NthIndexCache.h?l=36&gsn=NthIndexCache)
+ [`NthIndexCache`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/nth_index_cache.h?l=36&gsn=NthIndexCache)
* Ordering, e.g. the comment at the start of
[`MatchScopedRules`](https://cs.chromium.org/?q=symbol:%5Eblink::StyleResolver::MatchScopedRules$)
* How the collected set of rules that match an element are combined with
inline style and parent style to get computed-style.
* How the [various types of
- failure](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/SelectorChecker.h?l=153)
+ failure](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/selector_checker.h?l=153)
are used to optimize application of `MatchSelector`
* Other entry points that lead into rule collection.
* Animation.
diff --git a/third_party/blink/renderer/core/dom/README.md b/third_party/blink/renderer/core/dom/README.md
index 3f9d6688093daf..1beaa9238dbee8 100644
--- a/third_party/blink/renderer/core/dom/README.md
+++ b/third_party/blink/renderer/core/dom/README.md
@@ -1,6 +1,6 @@
# DOM
-[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/dom/README.md)
+[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/dom/README.md)
Author: hayato@chromium.org
diff --git a/third_party/blink/renderer/core/dom/ng/README.md b/third_party/blink/renderer/core/dom/ng/README.md
index ecd5eb92f97489..479a6b6c6fd06c 100644
--- a/third_party/blink/renderer/core/dom/ng/README.md
+++ b/third_party/blink/renderer/core/dom/ng/README.md
@@ -1,6 +1,6 @@
# DOM experimental
-[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/dom/ng/README.md)
+[Rendered](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/dom/ng/README.md)
Author: hayato@chromium.org
diff --git a/third_party/blink/renderer/core/html/custom/README.md b/third_party/blink/renderer/core/html/custom/README.md
index a85cf911b1393a..289833db2aaa38 100644
--- a/third_party/blink/renderer/core/html/custom/README.md
+++ b/third_party/blink/renderer/core/html/custom/README.md
@@ -74,7 +74,7 @@ Custom elements have small C++ unit tests and medium
###### C++ Unit Tests
-These are in third_party/WebKit/Source/core/dom/*Test.cpp and are
+These are in third_party/blink/renderer/core/dom/*_test.cc and are
built as part of the webkit_unit_tests target. The test names start
with CustomElement so you can run them with:
diff --git a/third_party/blink/renderer/core/layout/ng/BlockLayout.md b/third_party/blink/renderer/core/layout/ng/BlockLayout.md
index 86de3ba96a772c..33bf269638d957 100644
--- a/third_party/blink/renderer/core/layout/ng/BlockLayout.md
+++ b/third_party/blink/renderer/core/layout/ng/BlockLayout.md
@@ -1,6 +1,6 @@
# Block Layout #
-This document can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/layout/ng/BlockLayout.md).
+This document can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/layout/ng/BlockLayout.md).
## BFC & BFC Offsets ##
@@ -13,7 +13,7 @@ below) and floats do not intrude, the exclusion space is completely separate.
Our block layout implementation is based on the principle that children place
*themselves* within the block formatting context. This information is
-communicated with the optional [NGLayoutResult::BfcOffset](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/ng/ng_layout_result.h).
+communicated with the optional [NGLayoutResult::BfcOffset](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/ng/ng_layout_result.h).
A child's BFCOffset is optional as empty blocks cannot place themselves within
the BFC. They may be affected by siblings.
@@ -69,7 +69,7 @@ FloatsBFCOffset.
---
Once a float is positioned, everything else float related is handled by the
-[ExclusionSpace](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/ng/ng_exclusion_space.h).
+[ExclusionSpace](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/ng/ng_exclusion_space.h).
Mutating the exclusion space only happens by adding additional exclusions.
diff --git a/third_party/blink/renderer/core/layout/ng/README.md b/third_party/blink/renderer/core/layout/ng/README.md
index 85da73a14d48fa..08825d004fb106 100644
--- a/third_party/blink/renderer/core/layout/ng/README.md
+++ b/third_party/blink/renderer/core/layout/ng/README.md
@@ -3,7 +3,7 @@
This directory contains the implementation of Blink's new layout engine
"LayoutNG".
-This README can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/layout/ng/README.md).
+This README can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/layout/ng/README.md).
The original design document can be seen [here](https://docs.google.com/document/d/1uxbDh4uONFQOiGuiumlJBLGgO4KDWB8ZEkp7Rd47fw4/edit).
diff --git a/third_party/blink/renderer/core/layout/ng/inline/README.md b/third_party/blink/renderer/core/layout/ng/inline/README.md
index d38ab521395087..87d62fbb0b3f02 100644
--- a/third_party/blink/renderer/core/layout/ng/inline/README.md
+++ b/third_party/blink/renderer/core/layout/ng/inline/README.md
@@ -3,7 +3,7 @@
This directory contains the inline layout implementation
of Blink's new layout engine "LayoutNG".
-This README can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/layout/ng/inline/README.md).
+This README can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/layout/ng/inline/README.md).
Other parts of LayoutNG is explained [here](../README.md).
diff --git a/third_party/blink/renderer/core/layout/ng/list/README.md b/third_party/blink/renderer/core/layout/ng/list/README.md
index 4f49853c7128bb..9dbe472eaac39d 100644
--- a/third_party/blink/renderer/core/layout/ng/list/README.md
+++ b/third_party/blink/renderer/core/layout/ng/list/README.md
@@ -3,7 +3,7 @@
This directory contains the list implementation
of Blink's new layout engine "LayoutNG".
-This README can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/layout/ng/list/README.md).
+This README can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/layout/ng/list/README.md).
Other parts of LayoutNG is explained [here](../README.md).
diff --git a/third_party/blink/renderer/core/mojo/README.md b/third_party/blink/renderer/core/mojo/README.md
index ce395501355f5a..98562c8b0af710 100644
--- a/third_party/blink/renderer/core/mojo/README.md
+++ b/third_party/blink/renderer/core/mojo/README.md
@@ -3,7 +3,7 @@ This document is a subset of the [Mojo documentation](/mojo).
The JavaScript system API exposes the capabilities to create message pipes, data
pipes, shared buffers and watchers. The API is defined using Web IDL. You could
-find the IDL files [here](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/mojo/).
+find the IDL files [here](https://cs.chromium.org/chromium/src/third_party/blink/Source/core/mojo/).
Please refer to the low-level [C system API](/mojo/public/c/system) for more
detailed documentation of equivalent methods.
diff --git a/third_party/blink/renderer/core/paint/ng/README.md b/third_party/blink/renderer/core/paint/ng/README.md
index 633d27fc15729d..70c1fb9bb762b4 100644
--- a/third_party/blink/renderer/core/paint/ng/README.md
+++ b/third_party/blink/renderer/core/paint/ng/README.md
@@ -4,7 +4,7 @@ This directory contains the paint system to work with
the Blink's new layout engine [LayoutNG].
This README can be viewed in formatted form
-[here](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/paint/ng/README.md).
+[here](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/paint/ng/README.md).
## NGPaintFragment ##
diff --git a/third_party/blink/renderer/core/style/ComputedStyle.md b/third_party/blink/renderer/core/style/ComputedStyle.md
index 79d6cc76a35a06..0202460621a9da 100644
--- a/third_party/blink/renderer/core/style/ComputedStyle.md
+++ b/third_party/blink/renderer/core/style/ComputedStyle.md
@@ -1,7 +1,7 @@
# Files:
Currently the C++ code for ComputedStyle lies in the following sets of files:
-* ComputedStyleBase.{h,cpp} - This is the generated base class for ComputedStyle. All groups and fields are initialized here.
-* ComputedStyle.{h,cpp} - These files add the following things on top of ComputedStyleBase:
+* computed_style_base.{h,cc} - This is the generated base class for ComputedStyle. All groups and fields are initialized here.
+* computed_style.{h,cc} - These files add the following things on top of ComputedStyleBase:
* Handwritten public accessors that are not straightforward and hence not generated in ComputedStyleBase.
* Helper functions - e.g. functions that compare two ComputedStyle to check for equality across a set of fields.
@@ -12,20 +12,20 @@ The files that generate the code in ComputedStyleBase.{h,cpp} include:
## JSON files:
These files are inputs to the generator and tell the generator what shape our fields and functions take. This is a list of all the relevant JSON files (more detailed documentation can be found in the files themselves):
-* [CSSProperties.json5](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/CSSProperties.json5): Contains information for all the CSS properties we support.
-* [ComputedStyleExtraFields.json5](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/ComputedStyleExtraFields.json5): Specifies fields in ComputedStyle that we would like to generate, but are not CSS properties.
-* [ComputedStyleDiffFunctions.json5](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/ComputedStyleDiffFunctions.json5): Specifies the fields we want to diff in the various diff functions in ComputedStyle. It is used to generate the various diffing functions on ComputedStyle.
+* [CSSProperties.json5](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/CSSProperties.json5): Contains information for all the CSS properties we support.
+* [ComputedStyleExtraFields.json5](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/ComputedStyleExtraFields.json5): Specifies fields in ComputedStyle that we would like to generate, but are not CSS properties.
+* [ComputedStyleDiffFunctions.json5](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/ComputedStyleDiffFunctions.json5): Specifies the fields we want to diff in the various diff functions in ComputedStyle. It is used to generate the various diffing functions on ComputedStyle.
## Generator files:
These scripts generate the computed_style_base.{h,cc} files. This is a list of the relevant generator files (more detailed documentation can be found in the files themselves):
-* [make_computed_style_base.py](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/build/scripts/make_computed_style_base.py): Main file that handles the code generation logic. It consumes the JSON inputs provided and outputs fields and groups that encapsulate the structure of ComputedStyle.
+* [make_computed_style_base.py](https://cs.chromium.org/chromium/src/third_party/blink/renderer/build/scripts/make_computed_style_base.py): Main file that handles the code generation logic. It consumes the JSON inputs provided and outputs fields and groups that encapsulate the structure of ComputedStyle.
## Template files:
For each generate file, the Python script uses a Jinja template file to format the output:
-* [computed_style_base.h.tmpl](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/build/scripts/templates/computed_style_base.h.tmpl): Header file with the field and group declarations.
-* [computed_style_base.cc.tmpl](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/build/scripts/templates/computed_style_base.cc.tmpl): Implementation of various generated helper functions. Notably, contains implementation of functions that use ComputedStyle such as the diffing functions.
-* [computed_style_base_constants.h.tmpl](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/build/scripts/templates/computed_style_base_constants.h.tmpl): Definitions of generated enums.
-* [fields/*.tmpl](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/build/scripts/templates/fields/): These files contain various macros that help us generate accessors for the fields depending on their field_template.
+* [computed_style_base.h.tmpl](https://cs.chromium.org/chromium/src/third_party/blink/renderer/build/scripts/templates/computed_style_base.h.tmpl): Header file with the field and group declarations.
+* [computed_style_base.cc.tmpl](https://cs.chromium.org/chromium/src/third_party/blink/renderer/build/scripts/templates/computed_style_base.cc.tmpl): Implementation of various generated helper functions. Notably, contains implementation of functions that use ComputedStyle such as the diffing functions.
+* [computed_style_base_constants.h.tmpl](https://cs.chromium.org/chromium/src/third_party/blink/renderer/build/scripts/templates/computed_style_base_constants.h.tmpl): Definitions of generated enums.
+* [fields/*.tmpl](https://cs.chromium.org/chromium/src/third_party/blink/renderer/build/scripts/templates/fields/): These files contain various macros that help us generate accessors for the fields depending on their field_template.
# Understanding where to make changes:
When we want to generate something in ComputedStyle, it’s usually as simple as adding a new entry to the JSON file or modifying a particular value. However, there can be cases where the thing to generate does not fit the current framework and more drastic changes are required. These changes can be done in several different places, but some are more preferable than others (most preferable to least preferable):
diff --git a/third_party/blink/renderer/devtools/readme.md b/third_party/blink/renderer/devtools/readme.md
index 8fee41f44ee5b6..1f7a75afaee616 100644
--- a/third_party/blink/renderer/devtools/readme.md
+++ b/third_party/blink/renderer/devtools/readme.md
@@ -8,7 +8,7 @@ It is available on NPM as the [chrome-devtools-frontend](https://www.npmjs.com/p
The version number of the npm package (e.g. `1.0.373466`) refers to the Chromium commit position of latest frontend git commit. It's incremented with every Chromium commit, however the package is updated roughly daily.
### Source code
-The frontend is available through a git subtree mirror on [chromium.googlesource.com](https://chromium.googlesource.com/chromium/src/third_party/WebKit/Source/devtools/), with a regularly updating GitHub mirror at [github.com/ChromeDevTools/devtools-frontend](https://github.com/ChromeDevTools/devtools-frontend). The codebase's true location is in `third_party/WebKit/Source/devtools/` in [Chromium's git repo](https://chromium.googlesource.com/chromium/src/).
+The frontend is available through a git subtree mirror on [chromium.googlesource.com](https://chromium.googlesource.com/chromium/src/third_party/blink/renderer/devtools/), with a regularly updating GitHub mirror at [github.com/ChromeDevTools/devtools-frontend](https://github.com/ChromeDevTools/devtools-frontend). The codebase's true location is in `third_party/blink/renderer/devtools/` in [Chromium's git repo](https://chromium.googlesource.com/chromium/src/).
### Getting Started
@@ -118,7 +118,7 @@ npm test -- --target=Default
[devtools-reviews@chromium.org]: https://groups.google.com/a/chromium.org/forum/#!forum/devtools-reviews
[RSS feed]: https://feeds.peter.sh/chrome-devtools/
- [View the log]: https://chromium.googlesource.com/chromium/src/third_party/WebKit/Source/devtools/+log/master
+ [View the log]: https://chromium.googlesource.com/chromium/src/third_party/blink/renderer/devtools/+log/master
[@ChromeDevTools]: http://twitter.com/ChromeDevTools
[@DevToolsCommits]: http://twitter.com/DevToolsCommits
[all open DevTools tickets]: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3APlatform%3EDevTools&sort=&groupby=&colspec=ID+Stars+Owner+Summary+Modified+Opened
diff --git a/third_party/blink/renderer/modules/indexeddb/README.md b/third_party/blink/renderer/modules/indexeddb/README.md
index 5d72211e30c093..39c3c33a6db2ec 100644
--- a/third_party/blink/renderer/modules/indexeddb/README.md
+++ b/third_party/blink/renderer/modules/indexeddb/README.md
@@ -21,8 +21,8 @@ implementation.
Please add documents below as you write it.
-* [Overview for Database People](/third_party/WebKit/Source/modules/indexeddb/docs/idb_overview.md)
-* [IndexedDB Data Path](/third_party/WebKit/Source/modules/indexeddb/docs/idb_data_path.md)
+* [Overview for Database People](/third_party/blink/renderer/modules/indexeddb/docs/idb_overview.md)
+* [IndexedDB Data Path](/third_party/blink/renderer/modules/indexeddb/docs/idb_data_path.md)
## Design Docs
diff --git a/third_party/blink/renderer/modules/sensor/README.md b/third_party/blink/renderer/modules/sensor/README.md
index 4f076da241fad1..b3b3faabe85f8f 100644
--- a/third_party/blink/renderer/modules/sensor/README.md
+++ b/third_party/blink/renderer/modules/sensor/README.md
@@ -1,6 +1,6 @@
# Generic Sensor
-`third_party/WebKit/Source/modules/sensor` implements the following concrete
+`third_party/blink/renderer/modules/sensor` implements the following concrete
sensor intrefaces based on the [Generic Sensor API]
(https://w3c.github.io/sensors):
1. [Ambient Light Sensor] (https://w3c.github.io/ambient-light)
diff --git a/third_party/blink/renderer/platform/bindings/TraceWrapperReference.md b/third_party/blink/renderer/platform/bindings/TraceWrapperReference.md
index 0d0ad337dac607..fa32b874f7faef 100644
--- a/third_party/blink/renderer/platform/bindings/TraceWrapperReference.md
+++ b/third_party/blink/renderer/platform/bindings/TraceWrapperReference.md
@@ -76,7 +76,7 @@ Note that *wrappables* have to be *on-heap objects* and thus all
[Oilpan-related rules][oilpan-docs] apply.
[object-grouping-slides]: https://docs.google.com/presentation/d/1I6leiRm0ysSTqy7QWh33Gfp7_y4ngygyM2tDAqdF0fI/
-[oilpan-docs]: https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/platform/heap/BlinkGCAPIReference.md
+[oilpan-docs]: https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md
## Basic usage
@@ -84,8 +84,8 @@ The annotations that are required can be found in the following header files.
Pick the header file depending on what types are needed.
```c++
-#include "platform/bindings/ScriptWrappable.h"
-#include "platform/bindings/TraceWrapperV8Reference.h"
+#include "third_party/blink/renderer/platform/bindings/script_wrappable.h"
+#include "third_party/blink/renderer/platform/bindings/trace_wrapper_v8_reference.h"
```
The following example will guide through the modifications that are needed to
diff --git a/third_party/blink/renderer/platform/fonts/README.md b/third_party/blink/renderer/platform/fonts/README.md
index fffa2ef99c140b..7891fbad18a201 100644
--- a/third_party/blink/renderer/platform/fonts/README.md
+++ b/third_party/blink/renderer/platform/fonts/README.md
@@ -2,7 +2,7 @@
This README serves as an documentation entry point of Blink's text stack.
-It can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/platform/fonts/README.md).
+It can be viewed in formatted form [here](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/fonts/README.md).
## Overview ##
@@ -12,9 +12,9 @@ CSS-styled HTML text.
The API methods
in
-[Font.h](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/shaping/Font.h) describe
+[font.h](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/shaping/font.h) describe
the interface between the layout code and the font
-code. [Font.h](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/shaping/Font.h) provides
+code. [font.h](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/shaping/font.h) provides
API for mainly three kinds of requests coming from the layout and paint code:
- Measuring text
@@ -38,23 +38,23 @@ From source HTML to visual output this roughly comprises the following stages:
During
the
-[style resolution](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp?type=cs&l=1028) stage
+[style resolution](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/resolver/style_resolver.cc?type=cs&l=1028) stage
of
layout
-[`ComputedStyle`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/style/ComputedStyle.h) objects
+[`ComputedStyle`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/style/computed_style.h) objects
are calculated for each element of the DOM tree. Each `ComputedStyle` will own
a
-[`Font`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/Font.h) and
+[`Font`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/font.h) and
a
-[`FontDescription`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/FontDescription.cpp) object.
+[`FontDescription`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/font_description.cc) object.
For this to work, after CSS is parsed into the various specialized
`CSSValue`-derived types, the `ConvertFont…` methods
in
-[`StyleBuilderConverter.cpp`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/resolver/StyleBuilderConverter.cpp) convert
+[`style_builder_converter.cc`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/resolver/style_builder_converter.cc) convert
from `CSSValue`s to `FontDescription` data structures. In the opposite
direction, the `ValueForFont…` methods
in
-[`ComputedStyleCSSValueMapping.cpp`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp) convert
+[`computed_style_css_value_mapping.cc`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/computed_style_css_value_mapping.cc) convert
back from `FontDescription` back to CSS values.
Then, during style resolution, `FontBuilder::CreateFont` is called to update the
@@ -98,7 +98,7 @@ to perform a lookup. `CSSFontSelector` will in turn ask `FontFaceCache` to find
a FontData object among the available web fonts. If there is already a match for
`FontDescription` in the cache, this `FontData` object is returned. If not,
the
-[`FontSelectionAlgorithm::IsBetterMatchForRequest`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/FontSelectionAlgorithm.h?l=44) comparison
+[`FontSelectionAlgorithm::IsBetterMatchForRequest`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/font_selection_algorithm.h?l=44) comparison
function is used to find the best match among the available web fonts. This
comparison function implements
the
@@ -109,10 +109,10 @@ a font from the system. To this end, it will query `FontCache`. `FontCache` is
for system fonts what `FontFaceCache` is for web fonts. `FontCache` has
OS/system specific implementations
in
-[FontCacheSkia.cpp](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp),
-[FontCacheMac.mm](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/mac/FontCacheMac.mm),
-[FontCacheLinux.cpp](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/linux/FontCacheLinux.cpp),
-[FontCacheAndroid.cpp](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/android/FontCacheAndroid.cpp) in
+[font_cache_skia.cc](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/skia/font_cache_skia.cc),
+[font_cache_mac.mm](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/mac/font_cache_mac.mm),
+[font_cache_linux.cc](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/linux/font_cache_linux.cc),
+[font_cache_android.cc](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/android/font_cache_android.cc) in
order to perform system font lookups using the respective OS/system API.
## Excursion: Setting up Shaping
@@ -187,14 +187,14 @@ the set of available fonts at the time shaping for this word and its
`FontDescription` was performed. This state is captured by computing a composite
key off of the `FontFallbackList`
in
-[`FontFallbackList::CompositeKey`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp?l=186).
+[`FontFallbackList::CompositeKey`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/font_fallback_list.cpp?l=186).
### Accessing the Cache
-[`CachingWordShaper.h`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/shaping/CachingWordShaper.h) is
+[`cachin_gword_shaper.h`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/shaping/caching_word_shaper.h) is
the entry point for retrieving shaping results through the word cache. It defers
to
-[`CachingWordShapeIterator.h`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/shaping/CachingWordShapeIterator.h) for
+[`caching_word_shape_iterator.h`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/shaping/caching_word_shape_iterator.h) for
word/space or CJK segmentation and responds to requests for a `TextRun`'s
`Width()` or returns a `ShapeResultBuffer`containing a list of `ShapeResult`
objects. If not found in the cache `ShapeResult` objects are produced by
@@ -206,17 +206,17 @@ accelerating caching layer between `Font` operations and `HarfBuzzShaper`.
The section [Setting up Shaping](#excursion_setting-up-shaping) described the
requirements for constant input requirements before shaping can be performed.
-[RunSegmenter](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/shaping/RunSegmenter.h) is
+[RunSegmenter](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/shaping/run_segmenter.h) is
the top level API for segmenting incoming text runs using sub-segmenters. It
splits text by their Unicode script property
(via
-[`ScriptRunIterator`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/ScriptRunIterator.h)),
+[`ScriptRunIterator`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/script_run_iterator.h)),
orientation and direction — horizontal LTR/RTL, vertical LTR/RTL
(via
-[`OrientationIterator`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/OrientationIterator.h)),
+[`OrientationIterator`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/orientation_iterator.h)),
and emoji presentation attributes
(via
-[`SymbolsIterator`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/SymbolsIterator.h)).
+[`SymbolsIterator`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/symbols_iterator.h)).
`RunSegmenter` is constructed from a text run in UTF-16 `UChar` format, then
functions as an iterator returning sub-runs of constant script, emoji
@@ -227,8 +227,8 @@ shaping.
The text shaping implementation is
in
-[shaping/HarfBuzzShaper.h](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.h) and
-[shaping/HarfBuzzShaper.cpp](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.cpp)
+[shaping/harf_buzz_shaper.h](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/shaping/harf_buzz_shaper.h) and
+[shaping/harf_buzz_shaper.cc](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/shaping/harf_buzz_shaper.cc)
Shaping text runs is split into several
stages: [Run segmentation](#Run-Segmentation), shaping the initial segment
@@ -347,7 +347,7 @@ fill gaps from the secondary font and so on until there are no more so called
fill such gaps. `FontFallbackIterator` is an iterator style API, which on
calling `next()` will deliver the first suitable font to
try. A
-[`FontFallbackList`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/FontFallbackList.h) is
+[`FontFallbackList`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/font_fallback_list.h) is
the internal representation of fonts resolved from the CSS `font-family:`
property. `FontFallbackList` attempts to resolve font family names from the CSS
`font-family:` property in descending order. It tries to find them among the
@@ -371,7 +371,7 @@ screen. In this situation, system font fallback is invoked, which means
attempting to find a surrogate font which contains those glyphs that were
missing so far. To this end `FontFallbackIterator`
calls
-[`FontCache::FallbackFontForCharacter()`](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/FontCache.h?type=cs&q=fallbackFontForCharacter) in
+[`FontCache::FallbackFontForCharacter()`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/font_cache.h?type=cs&q=fallbackFontForCharacter) in
order to retrieve a font that has a glyph for the requested Unicode
character. This means, beyond what is listed in `font-family` there are
additional system fonts pulled in to the shaping process.
diff --git a/third_party/blink/renderer/platform/wtf/README.md b/third_party/blink/renderer/platform/wtf/README.md
index 91b1a188b5e1b8..be3012efb34ad6 100644
--- a/third_party/blink/renderer/platform/wtf/README.md
+++ b/third_party/blink/renderer/platform/wtf/README.md
@@ -92,30 +92,30 @@ but it moved to Source/WTF/wtf in 2011-2012, then to Source/wtf in 2013.
Blink forked WebKit in 2013. In 2017, the directory finally [moved to the
current location][4] Source/platform/wtf.
-[the directory listing]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/
+[the directory listing]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/
[base]: https://cs.chromium.org/chromium/src/base/
-[Vector]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Vector.h
-[HashSet]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/HashSet.h
-[HashMap]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/HashMap.h
-[Deque]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Deque.h
-[String]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/text/WTFString.h
-[AtomicString]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/text/AtomicString.h
-[StringBuilder]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/text/StringBuilder.h
-[CString]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/text/CString.h
-[RefCounted]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/RefCounted.h
-[Allocator.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Allocator.h
-[Functional.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Functional.h
-[Threading.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Threading.h
-[ThreadingPrimitives.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/ThreadingPrimitives.h
-[Compiler.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Compiler.h
-[CPU.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/CPU.h
-[build_config.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/build_config.h
-[Noncopyable.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Noncopyable.h
-[StdLibExtras.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/StdLibExtras.h
-[Time.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Time.h
-[CryptographicallyRandomNumber.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/CryptographicallyRandomNumber.h
-[AutoReset.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/AutoReset.h
-[Optional.h]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Optional.h
+[Vector]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/vector.h
+[HashSet]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/hash_set.h
+[HashMap]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/hash_map.h
+[Deque]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/deque.h
+[String]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/text/wtf_string.h
+[AtomicString]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/text/atomic_string.h
+[StringBuilder]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/text/string_builder.h
+[CString]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/text/cstring.h
+[RefCounted]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/ref_counted.h
+[Allocator.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/allocator.h
+[Functional.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/functional.h
+[Threading.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/threading.h
+[ThreadingPrimitives.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/threading_primitives.h
+[Compiler.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/compiler.h
+[CPU.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/cpu.h
+[build_config.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/build_config.h
+[Noncopyable.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/noncopyable.h
+[StdLibExtras.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/std_lib_extras.h
+[Time.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/time.h
+[CryptographicallyRandomNumber.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/cryptographically_random_number.h
+[AutoReset.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/auto_reset.h
+[Optional.h]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/optional.h
[1]: https://chromium.googlesource.com/chromium/src/+/e372c152fc6e57743ebc508fe17f6eb131b4ff8d
[2]: https://chromium.googlesource.com/chromium/src/+/547a6ca360a56fbee3d5ea4a71ba18f91622455c
[3]: https://chromium.googlesource.com/chromium/src/+/478890427ee03fd88e6f0f58ee8220512044bed9/third_party/WebKit/WebCore/kwq/KWQAssertions.h