WIP: Update Web Inspector docs:

- Added Overview of Web Inspector
- Removed WebReplay page
- Tweaks to language

docs/Deep Dive/Web Inspector/AnIntroduction.md

@@ -1,13 +1,13 @@
 # Introduction
 
-The Web Inspector allows you to view the page source, live DOM hierarchy, script debugging, profiling and more!
+Web Inspector allows you to view the page source, live DOM hierarchy, script debugging, profiling and more!
 
-## Enabling the Web Inspector
+## Enabling Web Inspector
 
 ### Safari
 
 * Enable the Develop menu option in the Advanced preferences.
-* Use the optional toolbar button, Develop menu or Inspect Element context menu to access the Web Inspector.
+* Use the optional toolbar button, Develop menu or Inspect Element context menu to access Web Inspector.
 
 ### Other WebKit clients
 
@@ -18,11 +18,13 @@ The Web Inspector allows you to view the page source, live DOM hierarchy, script
 defaults write "bundle-identifier-here" WebKitDeveloperExtras -bool true
 ```
 
-* Relaunch the application in order to use the Web Inspector
+* Relaunch the application in order to use Web Inspector
 
-## Using the Web Inspector
+## Using Web Inspector
 
-The Web Inspector can be opened by '''right clicking anywhere on a web page''' and choosing '''Inspect Element'''.  Once open, it highlights the node on the page as it is selected in the hierarchy. You can also search for nodes by node name, id and CSS class name.
+The most complete resource for Web Inspector is the [Web Inspector Reference](https://webkit.org/web-inspector/), and help links in Web Inspector itself can take you to help specific to the current part of the tools you are using.
+
+Web Inspector can be opened by '''right clicking anywhere on a web page''' and choosing '''Inspect Element'''.  Once open, it highlights the node on the page as it is selected in the hierarchy. You can also search for nodes by node name, id and CSS class name.
 
 The Node pane shows the current node type and name, as well as any element attributes.
 
@@ -32,11 +34,11 @@ The Metrics pane provides a quick visual look at how margins, borders and paddin
 
 Various HTML and JavaScript properties, including length of text nodes, offsetWidth/Height, class names, and parent/sibling information are vieweable in the Properties pane.
 
-See [Safari User Guide for Web Developers](http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/UsingtheWebInspector/UsingtheWebInspector.html) for more details on other panels of the Web Inspector.
+See [Safari User Guide for Web Developers](http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/UsingtheWebInspector/UsingtheWebInspector.html) for more details on other panels of Web Inspector.
 
-## Hacking on the Web Inspector
+## Hacking on Web Inspector
 
-Most of the Web Inspector's code is HTML, JavaScript, and CSS—so it's very easy to implement new features and fix bugs!
+Most of Web Inspector's code is HTML, JavaScript, and CSS—so it's very easy to implement new features and fix bugs!
 
 [List Web Inspector bugs and feature requests](http://tinyurl.com/2vqypl)
 
@@ -120,7 +122,7 @@ Most of the Web Inspector's code is HTML, JavaScript, and CSS—so it's very eas
 | Edit Breakpoint Condition     | Right-Click on line number | Right-Click on line number |
 
 
-## Using the Web Inspector remotely
+## Using Web Inspector remotely
 
 ### Remote Web Inspector on GTK+ and EFL ports
 

docs/Deep Dive/Web Inspector/Contributing.md

@@ -1,28 +1,55 @@
 # Contributing to Web Inspector
 
-## Modifying the Web Inspector
+The process for contributing to Web Inspector is the same as for [contributing to WebKit](/Getting%20Started/ContributingCode.html).
 
-The Web Inspector user interface is implemented using JavaScript, CSS, and HTML. So, it's relatively easy to dig into the Web Inspector's sources and fix bugs or add new features.
+This page provides an overview of Web Inspector and some techniques useful when working on Web Inspector.
 
-This wiki page documents the minimal steps required to modify styles used by the Web Inspector and submit your changes as a patch for review.
+## Overview of Web Inspector
 
-Let's say, we don't like red color for CSS property names, and we would prefer property names to be purple instead. Let's get started!
+Web Inspector consists of two main parts:
 
-## Inspect The Inspector
+- the frontend, which is the user interface a developer interacts with.
+- the backend, which instruments the inspected target, such as a web page.
 
-Since the Web Inspector UI is just another web page, we can inspect the Web Inspector with a second-level Web Inspector instance to quickly see what's going on. This requires a few magic settings to enable the "Inspect..." context menu on the Web Inspector window.
 
-For the Mac port, set the following defaults to allow inspecting the inspector.
+### Frontend
+The Web Inspector frontend is implemented using JavaScript, CSS, and HTML in files under `Source/WebInspectorUI/`.
 
-```
-defaults write NSGlobalDomain WebKitDebugDeveloperExtrasEnabled -bool YES
-```
+It follows a Model-View-Controller (MVC) approach. Models are representations of the inspectable objects, events, and resources. Views are responsible for laying out the user interface and responding to user interaction. Controllers orchestrate the data flow between models and views.
+
+
+### Backend
+The Web Inspector backend is written primarily in C++. It collects representations of things on the inspected target, like DOM nodes, network requests and responses, scripts, stylehseets, events, etc. It also implements ways to observe, change and block resources, and override behaviors of the inspected target.
+
+The files for the backend are more spread out. Find them under:
+
+- `Source/JavaScriptCore/inspector`
+- `Source/WebCore/inspector`
+- `Source/WebKit/UIProcess/inspector`
+- `Source/WebKit/WebProcess/inspector`.
+
+
+### Protocol
+The frontend and backend communicate via a JSON-based protocol which facilitates the exchange of messages with typed data payloads.
 
+Protocol messages describe commands and events. Commands are invoked by the frontend on the backend, such as requesting a list of resources or updating the contents of a resource. Events are dispatched by the backend to be handled by the frontend, such as the notification that a new resource has been added.
 
-After updating these settings, run the [https://developer.apple.com/safari/technology-preview/ Safari Technology Preview]. Then, open the Web Inspector and right-click to inspect the inspector itself.
+The files for the inspector protocol definitions are found under `Source/JavaScriptCore/inspector/protocol`.
 
-By inspecting the CSS property names in the second-level inspector, we quickly find that the colors are defined by rules in `Source/WebInspectorUI/UserInterface/Views/SpreadsheetCSSStyleDeclarationEditor.css`. 
-To create and submit a patch with our changes, we must to create an accompanying Bugzilla bug, and compute the diff of our changes against WebKit trunk.
+## Inspecting Web Inspector
+
+Since the Web Inspector user interface is a web page, you can inspect it with a second-level Web Inspector instance.
+
+To enable this, open the Settings tab of Web Inspector. Under the Experimental section, enable "Allow Inspecting Web Inspector". This enables the "Inspect Element" context menu item within Web Inspector itself.
+
+You can also observe the exchange of protocol messages between the backend and frontend.
+To do this, you must first enable the debug user interface in the second-level Web Inspector.
+
+Press the keyboard shortcut Cmd-Opt-Shift-D to reveal additional buttons in the second-level Web Inspector tab bar. Click the button to dump all inspector message to the console. In the Console tab of the second-level Web Inspector, you can now see a live log of messages exchanged between the backend and frontend of the main Web Inspector.
+
+## Making changes to Web Inspector
+
+TBD
 
 ## Create / Update a Bug Report
 
@@ -33,7 +60,8 @@ The WebKit project uses "bugs" in Bugzilla for fixes, new features, and any othe
 
 So, the first step is to ensure that your proposed enhancement or fix has an associated bug.
 
-Once you find or create a bug report, make sure to add a comment stating your intent to work on the bug. 
+Once you find or create a bug report, make sure to add a comment stating your intent to work on the bug.
+
 This step is very important; comments on bugs in the Web Inspector Bugzilla component will automatically notify Web Inspector reviewers.
 
 This will allow them to answer any questions you may have about a proposed fix, and give feedback, pointers, and guidance for solving the issue.
@@ -45,7 +73,7 @@ This will allow them to answer any questions you may have about a proposed fix,
 ```
 git clone https://github.com/WebKit/WebKit.git WebKit
 cd WebKit
-git checkout -b purple_css_values
+git checkout -b BRANCH_NAME
 ```
 
  2. [Build WebKit](http://webkit.org/building/build.html)
@@ -54,7 +82,7 @@ git checkout -b purple_css_values
 Tools/Scripts/build-webkit --release
 ```
 
- A clean build takes 20-80 minutes depending on the vintage of your machine.
+ A clean build takes between a few minutes up to more than an hour depending on your machine.
 
  3. [Run it](http://webkit.org/building/run.html)
 

docs/Deep Dive/Web Inspector/WebInspectorDebugging.md

@@ -1,6 +1,6 @@
-# Debugging the Web Inspector
+# Debugging Web Inspector
 
-This page contains tips and suggested workflows for isolating, understanding, and fixing code in the Web Inspector, particularly in the user interface.
+This page contains tips and suggested workflows for isolating, understanding, and fixing code in Web Inspector, particularly in the user interface.
 
 ## Inspecting the Inspector
 

docs/Deep Dive/Web Inspector/WebInspectorTests.md

@@ -1,6 +1,6 @@
 # Writing Web Inspector Tests
 
-This page describes how various parts of the Web Inspector are tested.
+This page describes how various parts of Web Inspector are tested.
 
 -----
 
@@ -13,7 +13,7 @@ There are several types of inspector tests:
  * **Manual Tests** exercise the user interface in ways that are difficult to automate or require infrastructure that doesn't exist yet.
  * **Library Tests** exercise subsystems such as pretty printing or the protocol generator in isolation from a running Web Inspector instance.
 
-To date, the Web Inspector has no automated tests that exercise the user interface. In practice, the Inspector UI changes frequently, so such tests tend to be brittle, and have traditionally not been worth the trouble of maintaining.
+Web Inspector does not have automated tests that exercise the user interface. In practice, the Inspector UI changes frequently, so such tests tend to be brittle, and have traditionally not been worth the trouble of maintaining.
 
 ## How Tests Execute
 
@@ -99,7 +99,7 @@ An `AsyncTestSuite` executes its test cases asynchronously, one after another, b
 
 ## How to Debug Tests
 
-In general, the strategies for [wiki:"WebInspectorDebugging" debugging the Web Inspector] and debugging WebCore/WebKit2 apply the same to debugging inspector tests. Sometimes, tests can be more difficult to debug because the test harness' marshalling code can be broken by incorrectly written tests or bugs in the test harness. The test stubs provide several flags that enable extra or more reliable logging for debug purposes. Flags can be set in the corresponding `Test/TestStub.html` file for all test runs, or at the top of a `test()` method to only affect one test.
+In general, the strategies for [wiki:"WebInspectorDebugging" debugging Web Inspector] and debugging WebCore/WebKit2 apply the same to debugging inspector tests. Sometimes, tests can be more difficult to debug because the test harness' marshalling code can be broken by incorrectly written tests or bugs in the test harness. The test stubs provide several flags that enable extra or more reliable logging for debug purposes. Flags can be set in the corresponding `Test/TestStub.html` file for all test runs, or at the top of a `test()` method to only affect one test.
 
 For protocol tests: