Console Snippets are uniquely identified by name, which must be provided when creating them.

Creating Console Snippets

Console Snippets can be created by:

• selecting Console Snippet… when creating a resource
• selecting Create Console Snippet… in the context menu shown when clicking on the [Run Console Snippet…] in the Console Tab and Split Console

Once at least one Console Snippet has been created, a new Console Snippets section will appear in the Navigation Sidebar of the Sources Tab. This section also has a [Create Console Snippet].

All capabilities of the Console Command Line API are available inside Console Snippets.

Any modifications to the Console Snippet are automatically saved and will be used the next time the Console Snippet is run.

Running Console Snippets

Running a Console Snippet is as easy as:

• clicking on the [Run] that appears on hover in the Sources Tab
• pressing space or enter when selected in the Navigation Sidebar of the Sources Tab
• selecting it in the context menu shown when clicking on the [Run Console Snippet…] in the Console Tab and Split Console

The JavaScript contents of the Console Snippet will be evaluated in the Console as though they were typed into the Console Prompt, meaning they will use the currently selected execution context. Any results will appear in the Console right after the name of the Console Snippet.

The name given when creating a Symbolic Breakpoints can also be case insensitive and/or interpreted as a regular expression pattern.

Symbolic Breakpoints can be added by selecting Symbolic Breakpoint… after clicking on the [Create Breakpoint] in the top-right of the Breakpoints section in the Navigation Sidebar in the Sources Tab.

All Symbolic Breakpoints are preserved across Web Inspector sessions.

Configuration

Symbolic Breakpoints have a few different configuration options, reachable by right-clicking and selecting Edit Breakpoint… in the context menu.

The Condition input allows you to restrict the Symbolic Breakpoint to only pause JavaScript execution if the given JavaScript evaluates to a truthy value. This is useful for situations where you only want to pause JavaScript execution once a certain condition is met, such as a variable having a particular value. Keep in mind that the contained JavaScript is evaluated when the Symbolic Breakpoint is reached, and may cause additional side effects depending on the code you run as your condition.

Rather than execute arbitrary code, however, you may just want to ignore the first few times the Symbolic Breakpoint is reached. If this is the case, setting the Ignore input to any positive integer will prevent the Symbolic Breakpoint from pausing execution until it has been reached that many times.

Now you may be wondering what’s an Action. There are four different types:

• Log Message

  This is basically a “shortcut” for logging values using console.log. The string you provide behaves like a template literal, meaning you can evaluate arbitrary JavaScript so long as it’s inside a ${…}.

• Evaluate JavaScript

  Arguably the most powerful Symbolic Breakpoint Action, it allows you to evaluate any arbitrary JavaScript whenever that Symbolic Breakpoint is hit. The given JavaScript is executed as if it were right before the line of code, meaning it will have access to all variables available in that scope before the related line.

• Play Sound

  Adding one of these will cause Web Inspector to play a system beep sound whenever the Symbolic Breakpoint is hit.

• Probe Expression

  Probe Expression s can be thought of almost like a mini-Console. Each time the related Symbolic Breakpoint is hit, the Probe Expression is evaluated and the result is saved in the Probe panel in the Details Sidebar in the Sources Tab, allowing you to see how the result of the expression changes during the lifetime of your program. You can use this to observe changes to a specific variable (e.g. this), or to changes in an entire expression (e.g. this.foo === "bar").

If any Action is set, you can also configure the Symbolic Breakpoint to Automatically continue after evaluating. This will cause the Symbolic Breakpoint to become effectively “invisible”, in that it will never pause execution. Symbolic Breakpoints that Automatically continue after evaluating will have a small white triangle (“hollow”) in the icon:

State

Symbolic Breakpoints can either be enabled or disabled . Ideally, Symbolic Breakpoints will always be enabled , but there are a few reasons why they would be disabled :

• the Symbolic Breakpoint was manually disabled . Clicking (or right-clicking and selecting Enable Breakpoint or Disable Breakpoint in the context menu) on any breakpoint icon in the Navigation Sidebar in the Sources Tab will toggle between enabled and disabled .
• breakpoints have been globally disabled . The global breakpoint control is a button that looks just like a breakpoint located in the top of the Navigation Sidebar in the Sources Tab.

All enable/disable/delete toggles are available in the context menu when right-clicking on any Symbolic Breakpoint.

Icon legend:

• enabled (breakpoints globally enabled)
• enabled (breakpoints globally enabled) with auto-continue
• disabled (breakpoints globally enabled)
• disabled (breakpoints globally enabled) with auto-continue
• enabled (breakpoints globally disabled)
• enabled (breakpoints globally disabled) with auto-continue
• disabled (breakpoints globally disabled)
• disabled (breakpoints globally disabled) with auto-continue

DOM Tree

The Main Content Area shows a live visualization of the DOM of the inspected page, matching HTML behavior and semantics (e.g. collapsing whitespace).

Hovering over any DOM node will highlight it in the Page Overlay.

DOM nodes can be reordered by dragging, support double-clicking to edit any tag/attribute/text/etc., and (once editing) allow for tabbing to switch between editable content.

If a DOM node is not actually rendered in the inspected page, it will be displayed in greyscale. This can be disabled in the Elements pane of the Settings Tab.

Any DOM node with especially important states will have small badges after the opening tag:

• grid badges indicate that the DOM node has a CSS grid layout. Clicking it will toggle the CSS grid overlay for that DOM node in Page Overlay.
• flex badges indicate that the DOM node has a CSS flex layout. Clicking it will toggle the CSS flex overlay for that DOM node in Page Overlay.
• Event badges indicate that the DOM node has at least one DOM event listener. Clicking it will show a popover listing all event listeners for that DOM node, just like in the Node panel.
• Scroll badges indicate that the DOM node is scrollable.

Right-clicking on any DOM node in the DOM Tree (including those not in the Elements Tab) will show a context menu with a variety of useful actions, such as Log Element (saves the DOM node to a variable in the Console), adding/removing DOM Breakpoints, toggling CSS pseudo-classes, Add/Edit/Copy/Delete commands, and more.

The top-left of the Main Content Area shows a breadcrumb navigation from the main document element to the selected DOM node, allowing for quick selection of relative DOM nodes.

There are also some toggles in the top-right of the Main Content Area:

• Badges allows for choosing which of the above badges are shown next to DOM nodes in the DOM Tree.
• [Show Rulers] will enable page rulers and node border lines in the page overlay.
• [Force print media styles] will make the inspected page think that it’s being printed, which will cause any @media print CSS to apply.
• [Override user preferences] shows a popover with controls to override user preferences for color scheme, reduced motion and increased contrast. The overrides persist on the inspected page while Web Inspector is open.

• [Show compositing borders] will draw borders around and indicate the number repaints for each layer, just like in the Layers Tab.
• [Enable paint flashing] will cause layers to briefly flash red when they are repainted, just like in the Layers Tab.

Details Sidebar

• The Styles panel organizes the CSS applied to the selected DOM node in the DOM Tree by CSS selector specificity and DOM node inheritance.

  By default, the Styles panel is split out into a separate column if Web Inspector is wide enough to allow more information to be visible at the same time. This is enabled by the Show independent Styles sidebar checkbox in the Elements pane of the Settings Tab.

  Unless otherwise indicated, every part of each CSS ruleset is editable, including the condition text for @media, @supports, @container and similar CSS at-rules. Invalid declarations are indicated with a yellow highlight and have a tooltip briefly explaining why. Autocompletion is provided for CSS properties and relevant keyword/function values. Specialized editors for various CSS declaration values can be shown by clicking on the nearby image (e.g. color/gradient swatches, [Edit “cubic-bezier” function], [Edit “box-shadow”], etc.).

  CSS Custom Properties, also known as CSS variables, that are declared or inherited but are not used anywhere in the matching styles are hidden by default. To reveal them, click the button to show unused CSS variables.

  CSS selectors will gray out any part of the selector that doesn’t match the selected DOM node in the DOM Tree (or ancestor in the case of inherited CSS rulesets). Clicking on the icon next to the CSS selector will show a context menu with a variety of useful actions.

  • Author Style Sheet CSS Ruleset
  • Author Style Sheet CSS Ruleset for a CSS Pseudo-Element
  • User Style Sheet CSS Ruleset
  • User Style Sheet CSS Ruleset for a CSS Pseudo-Element
  • User Agent Style Sheet CSS Ruleset
  • User Agent Style Sheet CSS Ruleset for a CSS Pseudo-Element
  • Inspector Style Sheet CSS Ruleset
  • Inspector Style Sheet CSS Ruleset for a CSS Pseudo-Element
  • Inherited CSS Ruleset
  • DOM style Attribute CSS Declaration Block
  • Inherited DOM style Attribute CSS Declaration Block

   

  New CSS rulesets can be created by clicking the [Add new rule] in the bottom left. By default they will be added to the Inspector Style Sheet (which will be created if it does not already exist), but can instead be added to any existing style sheet by right-clicking. These CSS rulesets (and the Inspector Style Sheet) are not preserved across navigations or between Web Inspector sessions.

  The Classes button in the bottom right controls a shelf that lists all CSS classes of the selected DOM node in the DOM Tree, providing checkboxes to quickly toggle each and an input to add new CSS classes.

• The Computed panel visualizes the CSS box model and lists the computed value for every CSS property for the selected DOM node in the DOM Tree.

  By default the Properties section will only show CSS properties that have been modified by a CSS ruleset that applies to the selected DOM node in the DOM Tree. This can be changed by clicking on the [Filter] to Show All unmodified/inherited CSS properties and/or to Prefer Shorthands (when possible).

  CSS variables are split out into a separate Variables section to avoid cluttering the Properties section. You can view them ungrouped, all in one section, or grouped into separate sections by value type: colors, dimensions, numbers, and others.

• The Layout panel lists the nodes that act as CSS Grid and Flexbox containers on the inspected page and provides controls to toggle the specialized page overlay for each node, such as the CSS Grid overlay.

  To change the color of each page overlay, use the color swatch next to the corresponding node listed in the Layout panel.

  The CSS Grid page overlay can be configured with a set of options:

  • Track Sizes: shows a label with the user-authored value for the track size or auto if the value is not explicitly set. This helps visual inspection by matching the user-authored value set in CSS with the corresponding grid track on the page.
  • Line Numbers: shows a label with the ordinal and the reverse ordinal of explicit grid lines. The reverse ordinal is useful when referencing lines backward from the end. For example, 1 -4 means “the first and the fourth last”.
  • Line Names: shows a label with the user-defined name for a grid line or the implicit grid line name derived from a grid area name.
  • Area Names: shows a label with the user-defined name for a group of cells.
  • Extended Grid Lines: extends grid lines infinitely in their respective directions.

  The Flexbox page overlay can be configured so that flex items show the order number corresponding to the implicit order in the DOM or the explicit order set with the order CSS property value.

  Click the [Options] icon in the Grid or Flexbox section headers to toggle at once all the specialized page overlays of that type.

• The Font panel shows information about the primary font for the selected DOM node in the DOM Tree, providing computed values for both basic properties (e.g. size, style, weight, etc.) and advanced properties (e.g. ligatures, alternate glyphs, variations, etc.).

  When the primary font on the selected DOM node is a variable font, the Font panel shows editing controls for its variation axes. For each axis, it shows the axis tag (a 4 character identifier), an optional axis label, a slider control with the range of supported values, and an input field with the current axis value. While the input field is focused, hold the Arrow Up or Arrow Down keys on the keyboard to increment or decrement the value in precise steps. Hold the Shift or Option key to change the magnitude of the step.

  Using the controls to change a variation axis writes the value to a corresponding CSS property on the inline styles of the selected DOM node so you can see the results live on the inspected page.

• The Changes panel lists modified CSS declarations for either the selected DOM node in the DOM Tree or for all styles in the inspected page based on the Show only for selected node setting checkbox in the Elements pane of the Settings Tab.
• The Node panel contains more verbose representations of the attributes, accessibility data, JavaScript event listeners (including ancestors), and JavaScript object inheritance for the selected DOM node in the DOM Tree.

• The Layers panel is similar to the All Layers panel in the Layers Tab in that it shows basic information about each layer, but instead limits its scope to the selected DOM node and its descendants in the DOM Tree.

By default, each resource in the table is sorted based on when the resource request began. Columns can be shown/hidden by right-clicking on the header of the table and checking/unchecking the desired column. In addition to the columns shown above (Name, Domain, Type, Transfer Size, Time, and the Waterfall), there are also columns that can be shown for MIME Type, Method, Scheme, Status, Protocol, Initiator, Priority, IP Address, Connection ID, and Resource Size.

Resources in the table can be filtered either via the URL input or the resource type segmented controls found above the table. It’s also possible to keep the items currently in the table from being replaced during page navigations by checking Preserve Log.

Statistics about the resources currently shown in the table are listed below the table:

• [Domain Count] is the number of unique domains that were communicated with.
• [Resource Count] is the number of resources that have been loaded.
• [Total Resource Size] is the total uncompressed bytes of all resources.
• [Total Transfer Size] is the total bytes transferred over the network for all resources.
• [Redirect Count] is a count of all redirects made for all resources.
• [Load Time] is when the "load" event was fired.

Selecting a resource in the table will show a more dedicated view about that resource, including a number of different panes, each focusing on a particular aspect of that resource.

• The Preview pane displays the contents of the resource as if it were viewed in the Sources Tab.

• The Headers pane shows information about the request and response headers, including any redirects.

  Resources loaded from JavaScript will also have an [Call Stack] next to the Initiator that will show a popover with a stack trace when clicked.

• The Cookies pane parses and displays any request and response cookies in a table for easier readability.

• The Sizes pane includes details about the sizes of the various payloads involved with the request.

• The Timing pane graphs a resource timing data of the selected resource, broken down into distinct phases.

  This information is also shown in a popover when clicking on the activity bars of any resource in the Waterfall column of the table.

• The Security pane provides details about the security of the connection and certificate used to fetch the resource.

Sharing

To export data in the table into an HTTP Archive (HAR) file, click Export or by press ⌘ S. To import previously exported HAR files, click Import or drag-and-drop the files over Web Inspector. Imported HAR files are individually viewable by selecting that HAR file after clicking [Select HAR].

Controlling Resource Caching

Caching can sometimes get in the way of developing websites as it can prevent changes made to resources from taking effect as the previously cached version is used instead. The [Ignore Cache] toggle controls whether WebKit will use these cached resources for any future resource requests so long as Web Inspector is open. This toggle is persistent across Web Inspector sessions.

Timeline recordings can be started, stopped, or resumed via the [Start recording] (and [Stop recording]) button or by pressing space in the Timelines Tab. The current timeline recording can be cleared via the [Clear timeline] button or by pressing ⌘ K.

Resuming after having stopped will add any newly recorded activity to the end of the previously active timeline recording. Shift-clicking [Create new recording] or pressing ⇧ space will start a brand new timeline recording, completely separate from all other existing timeline recordings. The active timeline recording can be changed using the breadcrumbs at the top of the Main Content Area.

A new timeline recording is automatically created whenever the inspected page navigates if the Timelines Tab is currently active. When the Stop recording once page loads checkbox is checked, this navigation timeline recording will automatically stop:

• after 2s of no recordable activity
• 10s after the load event is fired
• 90s after the timeline recording started

Timeline recordings can also be started and stopped via console.profile and console.profileEnd, allowing for the code itself to have more fine grained control over what activity is recorded.

NOTE: JIT deoptimizations, breakpoints, code coverage, type profiler, and other debugging features are temporarily disabled during timeline recordings in order to maximize the performance of the inspected page and therefore measure realistic performance.

Selecting Ranges

The content of the overview graph is able to extend beyond the bounds of the Web Inspector window. Scrolling vertically in the overview graph will zoom the visible time range, adjusting the ratio of the number of pixels used to visualize each second. Clicking and dragging anywhere in the overview graph will adjust the selected time range, which will consequently affect what records are shown, effectively filtering out all other records.

Depending on on the scale of the overview graph, multiple records may be visually merged into a single record.

Clicking and dragging from the top of an existing selected time range will move that time range horizontally without adjusting its total duration. Clicking and dragging either of the start/end handles at the top of an existing selection will extend or collapse that time range without adjusting the other start/end handle.

Clicking on any record in the overview graph will select that record in the associated timeline. If the record is outside of the current selection range, it will be adjusted to include that record with some extra time padding before/after.

Double-clicking anywhere in the overview graph will clear the current selection.

Events View

The Events view plots data captured during a timeline recording into a combined overview graph as a series of records, allowing for a quick scan to know when there was activity.

In addition to the record bars, there are different vertical line markers that can appear in the overview graph during a timeline recording to indicate significant or noteworthy events.

If the Group By Resource checkbox is checked, records are organized by either the originating resource or the type of activity rather than each having their own row in the overview table.

The Events view contains a number of different timelines that group similar activity together. Timelines can be disabled by clicking on the Edit button above the list of timelines and unchecking the checkbox next to that timeline.

The disabled state of each timeline is preserved across Web Inspector sessions.

Selecting any one of these timelines will show a more specific and detailed view for the type(s) of activity it represents.

• The Screenshots timeline captures a screenshot of the viewport after every composite during the timeline recording, and also shows all images from console.screenshot.

• The Network Requests timeline is similar to the Network Tab in that it lists all network activity that occurred during the timeline recording.

• The Layout & Rendering timeline lists every style invalidation or recalculation, layout, composite, and paint that occurred during the timeline recording, including information about the size of each and a link to the JavaScript that triggered it (if applicable).

• The Media & Animations timeline lists all media elements (e.g. <video>), CSS animations, and CSS transitions, plotting the various DOM events dispatched by each over time during the timeline recording.

  This timeline is initially disabled because it can impact the performance of the inspected page during a timeline recording.

• The JavaScript & Events timeline samples JavaScript activity to produce call trees, organized either by the sequential entry to script (e.g. script evaluation, event dispatch, setTimeout, etc.) that contained the activity or as a time-independent combined call tree.

• The CPU timeline graphs the CPU usage of all threads related to the inspected page during the timeline recording, as well as lists additional statistics about the number and type of event listeners, timers, network activity, script entries, etc. that were executed during the timeline recording.

• The Memory timeline graphs a breakdown of the memory usage of the inspected page based on how that memory is used during the timeline recording.

  This timeline is initially disabled because it can impact the performance of the inspected page during a timeline recording.

• The JavaScript Allocations timeline lists all JavaScript heap snapshots that have been captured since Web Inspector was opened and also contains tools for comparing the existence and of objects in heap snapshots and visualizing the shortest path from any given object to the root global object.

  JavaScript heap snapshots are automatically captured when the timeline recording starts, right before the timeline recording ends, and every 10s during a timeline recording, but can also be manually captured at any time by clicking [Take snapshot] or via console.takeHeapSnapshot.

  This timeline is initially disabled because it can impact the performance of the inspected page during a timeline recording.

Frames View

The Frames view is essentially a different way of organizing the data captured during a recording. Rather than organize the data based on the “type” of activity (i.e. the various timelines in the Events view), the Frames view simply groups activity based on which rendering frame that activity occurred in.

JavaScript

Layout

Paint

Other

In the graph area, the x-axis represents the sequential list of rendering frames, while the y-axis represents the time it took for that frame to execute (lower or less is better). The horizontal lines for 30 FPS and and 60 FPS are general indicators of time (~33ms and ~16ms respectively) and the likely overall frames-per-second if all rendering frames took that amount of time to execute.

Sharing

Complete recordings can be exported by clicking Export or pressing ⌘ S. Previously exported recordings can later be be imported by clicking Import or via drag-and-drop.

Layers have a significant impact on rendering performance. Without layers, animating any DOM node would mean having to wastefully repaint the whole page on every frame. If the DOM node has its own layer, however, it may be possible to skip repainting entirely and instead simply recomposite the layers on screen. But the trade-off for these computational savings is memory cost. Creating too many layers (intentionally or otherwise) can have disastrous results on memory-constrained devices.

Visualizing Layers

The Main Content Area contains a live interactive visualization of the layer tree of the inspected page.

• Click and drag to rotate
• Right-click (or ⌃-click) and drag to pan
• Scroll to zoom

Understanding Layers

Basic information about each layer is shown in the All Layers panel in the Details Sidebar, such as a cumulative paint count and the memory cost.

Selecting a row in the All Layers panel in the Details Sidebar or clicking on any visualized layer in the Main Content Area will show information about the selected layer, such as its dimensions and one or more reasons for why it was created.

Clicking the go-to arrow for any layer will reveal the node for that layer in the DOM Tree in the Elements Tab.

Debugging Layers

There are toggles at the top of the Main Content Area that can help identify issues with layers.

• [Show compositing borders] will draw borders around and indicate the number repaints for each layer.

• [Enable paint flashing] will cause layers to briefly flash red when they are repainted.

All of these toggles are also available at the top of the Main Content Area in the Elements Tab.

Additionally, right-clicking on any node in the DOM Tree in the Elements Tab and selecting Reveal in Layers Tab will jump to the Layers Tab, find the layer the node is part of, and select it in both the Main Content Area and the All Layers panel in the Details Sidebar.

Running Audits

When the Start button is clicked, all enabled audits are run one by one in the order they appear in the Navigation Sidebar. Individual audits can be run by clicking the [Start] button that appears on hover. Pressing space will also run the selected audit.

Once an audit finishes running, results are shown inline, replacing any results from any previous results. Additionally, results are saved in separate Run 1, Run 2, …, Run N folders underneath a top-level Results folder in the Navigation Sidebar.

Audit Results

Each test case can have one of five different results.

• Pass represents a result where no issues were identified.
• Warning is a “pass with issues” in that there was nothing critically wrong, but there were things that should be changed.
• Failed means that critical issues were found.
• Error occurs if the test function threw an error while running.
• Unsupported is a special case that can be used to indicate when the data being tested isn’t supported by the current page (e.g. missing some API).

In addition to the result level, the start and elapsed time are shown for each individual test case. For imported test case results, the URL of the page the test case was run against is also shown.

Sharing Audits

All audits can be exported by clicking Export, pressing ⌘ S, or right-clicking and selecting Save Test (or Save Result). Previously exported audits can later be imported by clicking Import or via drag-and-drop, regardless of whether that particular audit is able to be run on the current page. Imported audits are also preserved across Web Inspector sessions.

Audit results are similarly exportable or importable, and although they are preserved across inspected page navigations, they are not preserved across Web Inspector sessions. If an test case result includes DOM nodes and was run on a page with the same URL as the inspected page, Web Inspector will attempt to find nodes in the inspected page that have the same CSS path, showing previews as if they were logged to the console for any matching nodes.

Default Audits

Web Inspector also provides a few audits by default:

• Demo Audit is a comprehensive tour of the functionality and interface of audits, and can be used as a starter template for writing custom audits.
• Accessibility includes a handful of test cases that check for DOM accessibility best practices on the inspected page in accordance with the WAI-ARIA specification, such ensuring that a title or alt is set on all <img>.

These default audits cannot be modified or removed, only disabled.

Editing Audits

Clicking the Edit button at the bottom of the Navigation Sidebar will enter Edit Mode where audits can be created, modified, enabled/disabled, and even entirely removed (NOTE: this cannot be undone). This is true for both individual test cases and entire groups, allowing for more control over which tests run and what they do. Disabled audits are hidden when not in Edit Mode.

Audits can be deleted when in Edit Mode by pressing delete.

Creating Audits

In addition to the default audits provided by Web Inspector and any new audits created in Web Inspector when in Edit Mode, it’s also possible to import custom audits into Web Inspector from a file. Audits use a simple and highly flexible JSON structure, of which there are two main types:

• groups

{
    "type": "test-group",
    "name": "...",
    "tests": [<audit 1>, <audit 2>, ..., <audit N>]
}

• test cases

{
    "type": "test-case",
    "name": "...",
    "test": "function() { ... }"
}

Each field of these structures has a specific input in Web Inspector when in Edit Mode.

async functions are allowed, as well as non-async functions that return a Promise. The only requirement is that the return value of the function or resolved Promise value conforms to the following rules:

• Returning true/false will translate to a Pass/Fail result with no additional data.
• Returning a string will translate to the corresponding result (e.g. "pass" is a Pass result) with no additional data.
• Returning an object gives the most flexibility, as it allows for additional data other than the audit’s result to be displayed in the Audit Tab. Result levels are first retrieved from the "level" property (if it exists), and are translated in the same way as if a string was returned (e.g. "level": "pass" is a Pass result). Alternatively, using any level as a key with a value of true will have the same effect (e.g. "pass": true). Additionally, there are three pieces of data that can be returned as part of the result object that have dedicated specialized interfaces:
  • domNodes is an array of DOM nodes that will be displayed in the Audit Tab much the same as if they were logged to the console.
  • domAttributes is an array of strings, each of which will be highlighted (if present) on any DOM nodes within domNodes.
  • errors is an array of Error and can be used as a way of exposing errors encountered while running the audit.
    • If this array has any values, the result of the audit is automatically changed to Error.
    • If an error is thrown while running an audit, it will automatically be added to this list.

Other custom data added to the result object will be displayed in the Audit Tab. Version 3

The audit JSON structure also support the following optional properties:

• description is a basic string that is displayed in the Audit Tab as a way of providing more information about that specific audit, such as what it does or what it’s trying to test.
• supports can be used as an alternative to feature checking, in that it prevents the audit from even being run unless the number value matches Web Inspector’s audit version number, which can be found at the bottom of the Main Content Area in the Audit Tab when in Edit Mode. The current version is 4.
• setup is a string similar to a test case’s test function, except that it is allowed on groups and only has an effect when supplied for a top-level audit (i.e. audits that are not inside a group). setup is evaluated before the rest of the audit runs, allowing for an easy way for code to be shared between all audits in a group without having to worry about which audits in that group are enabled/disabled. Version 2

Special Audit Functions

Since audits are run from Web Inspector, additional information is exposed to each test function being executed. This data available in Web Inspector is not accessible via JavaScript in any way.

The information is exposed via a WebInspectorAudit object that is exposed to each test function. Note that WebInspectorAudit is shared between all test functions under a given top-level audit. As such, attaching data to WebInspectorAudit to be shared between multiple test functions is accepted and encouraged, so long as that data doesn’t override any of the properties below.

Version

Accessing Web Inspector’s audit version number from within a test function is as simple as getting the value of WebInspectorAudit.Version. This number is also shown at the bottom of the Main Content Area in the Audit Tab when in Edit Mode. The current version is 4.

Resources

The following all relate to dealing with resources loaded by the page, and are held by WebInspectorAudit.Resources.

• getResources() returns a list of objects, each corresponding to a specific resource loaded by the inspected page, identified by a string url, string mimeType, and audit-specific id.
• getResourceContent(id) returns an object with the string data and boolean base64Encoded contents of the resource with the given audit-specific id.

DOM

The following all relate to dealing with the DOM, and are held by WebInspectorAudit.Resources.

• hasEventListeners(node[, type]) returns true/false depending on whether the given DOM node has any event listeners, or has an event listener for the given type (if specified).
• simulateUserInteraction(callback) will execute the given callback as though it was triggered by the user. Version 4

Accessibility

The following all relate to dealing with the accessibility tree, and are held by WebInspectorAudit.Accessibility. Further information can be found in the WAI-ARIA specification.

• getElementsByComputedRole(role[, container]) returns an array of DOM nodes that match the given role that are children of the container DOM node (if specified) or the main document.
• getActiveDescendant(node) returns the active descendant of the given DOM node.
• getMouseEventNode(node) returns the DOM node that would handle mouse events which is or is a child of the given DOM node.
• getParentNode(node) returns the parent DOM node of the given DOM node in the accessibility tree.
• getChildNodes(node) returns an array of DOM nodes that are children of the given DOM node in the accessibility tree.
• getSelectedChildNodes(node) returns an array of currently selected DOM nodes that are children of the given DOM node in the accessibility tree.
• getControlledNodes(node) returns an array of DOM nodes that are controlled by the given DOM node.
• getFlowedNodes(node) returns an array of DOM nodes that are flowed to from the given DOM node.
• getOwnedNodes(node) returns an array of DOM nodes that are owned by the given DOM node.
• getComputedProperties(node) returns an object that contains various accessibility properties for the given DOM node. Since HTML allows for “incorrect” values in markup (e.g. an invalid value for an attribute), the following properties use the computed value determined by WebKit:
  • busy is a boolean related to the aria-busy attribute.
  • checked is a string related to the aria-checked attribute.
  • currentState is a string related to the aria-current attribute.
  • disabled is a boolean related to the aria-disabled attribute.
  • expanded is a boolean related to the aria-expanded attribute.
  • focused is a boolean that indicates whether the given node is focused.
  • headingLevel is a number related to the aria-level attribute and the various HTML heading elements.
  • hidden is a boolean related to the aria-hidden attribute.
  • hierarchicalLevel is a number related to the aria-level attribute.
  • ignored is a boolean that indicates whether the given node is currently being ignored in the accessibility tree.
  • ignoredByDefault is a boolean that indicates whether the given node is always ignored by the accessibility tree.
  • invalidStatus is a string related to the aria-invalid attribute.
  • isPopUpButton is a boolean related to the aria-haspopup attribute.
  • label is a string related to the aria-label attribute
  • liveRegionAtomic is a boolean related to the aria-atomic attribute.
  • liveRegionRelevant is an array of strings related to the aria-relevant attribute.
  • liveRegionStatus is a string related to the aria-live attribute.
  • pressed is a boolean related to the aria-pressed attribute.
  • readonly is a boolean related to the aria-readonly attribute.
  • required is a boolean related to the aria-required attribute.
  • role is a string related to the role attribute.
  • selected is a boolean related to the aria-selected attribute.

Tab Bar

The Tab Bar has a list of tabs, each with a specific utility.

Tabs can be reordered by dragging, and can also be added/removed by right-clicking on the Tab Bar and checking/unchecking the item for the desired tab.

The Tab Bar also contains:

• docking configuration buttons:
  • docks Web Inspector to the left side of the inspected page. Only shown when Web Inspector is docked to the bottom/right of the inspected page or detached into its own window.
  • docks Web Inspector to the bottom of the inspected page. Only shown when Web Inspector is docked to the left/right of the inspected page or detached into its own window.
  • docks Web Inspector to the right side of the inspected page. Only shown when Web Inspector is docked to the left/bottom of the inspected page or detached into its own window.
  • detaches Web Inspector into its own window. Only shown when Web Inspector is docked to the left/bottom/right of the inspected page.
  • closes Web Inspector. Only shown when Web Inspector is docked to the left/bottom/right of the inspected page.
• controls for other functionality in the inspected page:
  • / toggles element selection mode. Can also be toggled by pressing ⇧ ⌘ C.
  • shows the device settings popover. Only shown for remote inspection.
  • reloads the inspected page. Can also be done by pressing ⌘ R. Only shown for remote inspection.
  • downloads the inspected page as a WebArchive. Can also be done by pressing ⌘ S in the Elements Tab. Only shown for remote inspection.
• Console indicators:
  • is shown if there are any warnings in the Console Tab. Clicking it will jump to the Console Tab and automatically set the message filters to only show warnings.
  • is shown if there are any errors in the Console Tab. Clicking it will jump to the Console Tab and automatically set the message filters to only show errors.
• pinned tabs:
  • allows for searching through all resources known to Web Inspector, respecting the global search settings. Can also be accessed by pressing ⇧ ⌘ F.
  • shows all of Web Inspector’s settings. Can also be accessed by pressing ⌘ ,.

If Web Inspector is too narrow, tabs are condensed into a [Show hidden tabs] which, when clicked, shows the list of enabled tabs that are not visible.

Navigation Sidebar

The Navigation Sidebar contains a list of items related to the selected tab. Selecting one of those items will update the Main Content Area and any related panels in the Details Sidebar

There is a filter bar at the bottom of every Navigation Sidebar that respects the global search settings to filter the list of items to make finding the right item easier.

Some tabs don’t have a Navigation Sidebar, in which case the Main Content Area is responsible for selecting and showing information about any of the tab’s known items. For tabs that do have a Navigation Sidebar, it can be expanded/collapsed by clicking on / or pressing ⇧ ⌘ 0.

Main Content Area

The Main Content Area shows a representation of the selected item in the Navigation Sidebar.

If the selected tab does not have a Navigation Sidebar, the Main Content Area will show the items related to the selected tab instead.

The top of the Main Content Area can contain:

• / expands/collapses the Navigation Sidebar.
•   history controls.
• Selection breadcrumbs that show the path of the selected item in the Navigation Sidebar. Clicking any item will show a context menu with items for each sibling of that item, allowing for quick hierarchical selection switching, or alternate representations of the currently shown content, such as switching between a resource’s request and response.
• One or more content-specific controls, each with unique functionality, such as:
  • creates a Local Override.
  • / toggles pretty printing for any text content.
  • / toggles JavaScript type profiling.
  • / toggles JavaScript code coverage.
  • / toggles the image transparency grid.
  • imports previously exported content.
  • exports the currently selected/shown content. Can also be done by pressing ⌘ S.
  • refreshes the visualization for selected/shown content.
  • clears the current content or deletes its backing data. Can also be done by pressing ⌘ K.
• / expands/collapses the Details Sidebar.

Details Sidebar

The Details Sidebar contains one or more panels which can be conditionally shown based on the selected item in the Navigation Sidebar or Main Content Area, each providing various types of additional information.

Some tabs don’t have a Details Sidebar, showing all information in the Main Content Area instead. For tabs that do have a Details Sidebar, it can be expanded/collapsed by clicking on / or pressing ⌥ ⌘ 0.

Split Console

The Split Console is a collapsable scrolling list of all logging activity, which shares content and state with the Console Tab.

Some tabs don’t allow the Split Console to be expanded as it wouldn’t fit with the layout of the rest of the tab. For tabs that do allow the Split Console, it can be expanded/collapsed by pressing esc or collapsed by clicking on [Collapse Split Console].

It is also possible to open the Console Tab from the Split Console by clicking on [Show Console Tab].

Console Prompt

The Console Prompt is an input field that allows you to evaluate arbitrary JavaScript in any execution context of the inspected page. These evaluations and their results will appear in both the Split Console and the Console Tab.

Execution contexts include <iframe>, Worker, and even isolated worlds created by browser extensions or other APIs. If there is more than one execution context in the inspected page, an execution context picker is shown at the right of the Console Prompt.

The Console Prompt can be focused by pressing esc or ⌃ `.

It may now be apparent from the above that Web Inspector has a ton of functionality across a wide swath of topics. But sadly there’s only so much space for links and buttons and all the other interface elements once the actual content of the page is taken into account. As such, Web Inspector leverages tooltips and context menus to add longer descriptions and/or provide additional functionality that’s perhaps not as frequently useful. Every icon throughout Web Inspector has a tooltip that explains the action of that icon (which is highlighted in these reference pages via [Tooltip Text]). Pictures of especially useful context menus are also included where pertinent, such as in the Elements Tab. It’s likely that Web Inspector is already able to do the thing you want, so when in doubt, try hovering to view the tooltip or right-clicking to show the context menu and see it there.

To enable Web Inspector in Safari (or Safari Technology Preview):

1. click the Safari (or Safari Technology Preview) menu bar item
2. select Preferences… (or press ⌘ ,)
3. go to the Advanced pane
4. check the Show Develop menu in menu bar checkbox

Show Web Inspector (or pressing ⌥ ⌘ I) in the Develop menu or by right-clicking on any page in Safari (or Safari Technology Preview) and selecting Inspect Element.

Once Web Inspector is enabled, the name of the current the macOS machine will appear as a submenu in the Develop menu of Safari (or Safari Technology Preview), allowing for inspection of:

• web content in developer provisioned applications or applications with the com.apple.webinspector.allow entitlement
  • WKWebView
  • WebView
  • JSContext

iOS Device

To enable remote inspection on an iOS device:

1. open the Settings app
2. go to Safari
3. scroll down to Advanced
4. enable the Web Inspector toggle

Once Web Inspector is enabled, connecting the iOS device to any macOS machine, either via a physical cable or after configuring wireless debugging in Xcode, the name of the iOS device will appear as a submenu in the Develop menu of Safari (and Safari Technology Preview) on the connected macOS machine, allowing for remote inspection of:

• any page in Safari
• websites added to the home screen
• web content in developer provisioned apps
  • SFSafariViewController
  • WKWebView
  • UIWebView
  • JSContext

NOTE: in order to use remote inspection, Web Inspector must be enabled on the connected macOS machine.

iOS Simulator

Remote inspection is always enabled for iOS simulators, meaning they will also appear in the Develop menu of Safari (and Safari Technology Preview) just like connected iOS devices.

Automatic Inspection

At the bottom of any macOS machine or iOS device submenu in the Develop menu of Safari (or Safari Technology Preview), there are two toggles:

• Automatically Show Web Inspector for JSContexts controls whether Web Inspector is automatically opened whenever a JSContext is created by any inspectable application on the corresponding macOS machine or iOS device.
• Automatically Pause Connecting to JSContexts controls whether Web Inspector automatically pauses JavaScript execution when inspecting any JSContext on the corresponding macOS machine or iOS device.

Appearance

Searching

Find Banner
Show find banner	⌘ F
Populate find from selection	⌘ E
When focused
Hide find banner	esc
Left-to-Right mode
Find next ( )	⌘ G
Find previous ( )	⇧ ⌘ G
Right-to-left mode
Find next ( )	⌘ G
Find previous ( )	⇧ ⌘ G

Tree Outlines

Text Editor

Content Browser

Navigation
Left-to-Right mode
Back ( )	⌃ ⌘ ←
Forward ( )	⌃ ⌘ →
Right-to-Left mode
Back ( )	⌃ ⌘ →
Forward ( )	⌃ ⌘ ←

Sidebars
Left-to-Right mode
Show / Hide Navigation Sidebar ( / )	⇧ ⌘ 0
Show / Hide Details Sidebar ( / )	⌥ ⌘ 0
Right-to-left mode
Show / Hide Navigation Sidebar ( / )	⇧ ⌘ 0
Show / Hide Details Sidebar ( / )	⌥ ⌘ 0

Quick Console

Navigation
Focus Console Prompt	esc or ⌃ `
Expand / Collapse Quick Console (   / )	esc

Message Log
Clear Console ( )	⌘ K or ⌃ L

Tab Navigation

Elements Tab

DOM Tree
Start / Stop element selection ( / )	⇧ ⌘ C
With one selected node
Copy node	⌘ C
Paste node	⌘ V
With one or more selected nodes
Hide selected element(s)	H
Remove element(s)	delete

Sources Tab

Debugger
Disable / Enable breakpoints ( / )	⌘ Y
Pause / Resume ( / )	⌃ ⌘ Y or ⌘ \
When paused
Step over ( )	⌘ ‘ or F6
Step into ( )	⌘ ; or F7
Step out ( )	⇧ ⌘ ; or F8
Step ( )	⇧ ⌘ ‘ or F9

Timelines Tab

Recording
Start / Stop recording ( / )	space or ⌥ ⇧ ⌘ T
Start new recording ( shift- )	⇧ space
Clear active recording ( )	⌘ K

Graphics Tab

Recording
Start / Stop canvas recording ( / )	space
Start single frame canvas recording ( shift- )	⇧ space

Audit Tab

Running Audits
Start / Stop running selected audit (   / )	space

Console Tab

Search Tab

Settings Tab