Extended grid lines are normally light fray, which makes them really
hard to see on some backgrounds.
This change makes extended grid lines use the same color as the lines
themselves, so they can be seen on all backgrounds more easily.
The grid container already has a solid line around it, so it's easy to
see where the grid starts and ends, even if lines and extended lines are
the same color.
Before/after: https://imgur.com/a/OvW46yn
Bug: 1207301
Change-Id: I5d363edf00acf8aa99e1d642c9088f0880286a10
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2897261
Reviewed-by: Leo Lee <leolee@microsoft.com>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Patrick Brosset <patrick.brosset@microsoft.com>
This issue is caused by an imperfect regex parsing for potential
animation-function-related keywords. Although "linear" is a keyword,
when it is suffixed by "-gradient", it is not a valid animation
function.
This is another example that using regex as a CSS syntax parser will
cause problems. For now this particular problem is fixed, but there
might be other cases that this regex will be false positive or negative.
Fixed: chromium:1203639
Change-Id: I81330260f0470693047c23f7eeb6c86639d5a125
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2896892
Auto-Submit: Changhao Han <changhaohan@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Some files currently rely on the Protocol to be available on the
global scope. However, the Protocol definitions are defined in
a .d.ts file, which isn't available on runtime. Therefore,
attempting to import Protocol with non-type imports would retain
the imports in the `.js` files and break on runtime.
Since the only usages of the Protocol on runtime are the enums,
we can make them const, such that they get inlined as intended.
Then, `import * as` will work again, as the enums are inlined and
the import is removed from the `.js` file.
DISABLE_THIRD_PARTY_CHECK=Protocol update
R=jacktfranklin@chromium.org
Bug: 1208357
Change-Id: I749e57c9f51596866b61cab686c59f00bc8a8eb4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2897277
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This CL fixes a bug that caused flickering when previewing documents
in the Preview pane in the network tab when clicking documents with the
preview pane already open. This bug was caused by 2 listeners
firing the code to re-render the preview pane in quick succession: one
from selecting a new grid node, and another from activating the
sidepane.
This CL updates the showRequestPane logic in the network panel to early
return if the request sidepane is already open, and we are not specifying
the sidepane tab when activating.
Bug: 1161690
Change-Id: Iabd86029c4c7fb636e2c93600534e0c272ee08ce
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2891083
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Patrick Brosset <patrick.brosset@microsoft.com>
Commit-Queue: Brandon Goddard <brgoddar@microsoft.com>
This CL changes how locale data is fetch to the same approach that
Lighthouse is using. The difference is, DevTools bundles more than
the en-US locale upfront, so we need to specify that explicitly.
Long term, we should have one central place where all the DevTools
locales are configured. That is, which ones are available, which
ones are shipped and which ones are fetched remotely. For now,
its configured in a few places.
R=tvanderlippe@chromium.org
Bug: chromium:1163928
Change-Id: Iba164eac05bab14a63301c7453f09021ee06991a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2882771
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
In order to dispatch lifecycle events from the backend the
`lifecycle_events_enabled_` flag in the page agent needs to be set to
true. This is done via the Page.setLifecycleEventsEnabled CDP method.
The ResourceTreeModel currently doesn't have an invoke to the CDP
method and so we add a new method to the class which includes it.
Bug: 1208453
Change-Id: I32ecc3ec680dbfedda2f9381a47ef0725a209ff2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2891444
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Andres Olivares <andoli@chromium.org>
In the Chromium backend engineers can use `DCHECK()` to ensure
certain invariants are held, but only execute these assertions
in a debug build. [1] Release builds do not ship with DCHECKS enabled.
In a similar fashion, introduce a build-time generated function
`DHCECK` that is only generated when `devtools_dcheck_always_on`
is set as GN arg. By default, `is_debug` builds enable
`devtools_dcheck_always_on`. However, in a release build, you can
explicitly set `devtools_dcheck_always_on` to `true` to achieve
the same effect.
When the GN arg is set, the build generates the `dcheck.js` file
with an implementation that checks the condition and fails if
it is not met. When the arg is not set, the function implementation
remains empty and becomes a noop.
To make sure that these functions calls are removed in a release
build (rather than being a noop), the terser configuration is
updated to treat these functions as pure. As such, terser will
remove any calls if the function implementation is empty. In a
release build that explicitly turns out the dchecks, terser
will not remove the function calls.
Lastly, to make sure that all code related to the dcheck is removed,
the condition needs to be a lambda. If we were to make it a raw
boolean, then `terser` would not be able to determine whether it
can remove the condition itself and would leave that behind. In other
words, the `DCHECK` call would still leave some artifacts behind,
namely the condition computation itself. By making it a lambda,
terser can deduce that the lambda creation has no side-effect and
remove the lambda if the `DHCECK` call is removed.
R=aerotwist@chromium.org
[1]: https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++.md#check_dcheck_and-notreached
Bug: none
Change-Id: Ic396f102141d9eb67c8690bd2a601b56061b9d8c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2894390
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL lints that for a given component that all the references to
its tag name are the same.
```
class Foo extends HTMLElement {
// Check that this name
static litTagName = LitHtml.literal\`devtools-foo\`
}
// And this name
ComponentHelpers.CustomElements.defineComponent('devtools-foo', Foo);
declare global {
interface HTMLElementTagNameMap {
// And this one are the same
'devtools-foo': Foo
}
}
```
Bug: 1153077
Change-Id: I29694449cb37950d1a5ff5391779e16e462926e2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2897279
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL updates our ESLint rule for custom event names:
* It changes it from wanting kebab-case to allonewordnopunctuation
* It allows references to CustomEvent.eventName for times when it's
useful to define the event name as a static.
The CL therefore updates a variety of events through the codebase that
were kebab-case. go/building-ui-devtools has also been updated.
Fixed: 1176758
Change-Id: Ifbe9851bc2f6bbe9347ec886cc8c026248cc5c43
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2894389
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Currently, all Protocol type definitions live on the global scope.
Additionally, the protocol files are included in all ts_library
targets. However, we don't want the protocol definitions to be
available in, for example, reusable UI components.
Therefore, we should move to a system where all files that want
to refer to the protocol types should import them instead.
However, doing so in 1 large CL will be problematic, which is
why it should be both globally available and importable as an
interim step.
To do so, we augment the existing protocol definitions to export
them as namespace and regular export. Then, we introduce a separate
file that imports the protocol types and augments the global scope
with the definitions. Now, protocol is both importable and remains
available on the global scope.
The reason that we need a separate file is that TypeScript disallows
you to augment the global scope in a file that also exports types.
Therefore, the global scope augmentation happens in protocol-globals.d.ts,
which will be removed once all Protocol type usages are imported.
To verify that this approach works, ProtocolClient imports the
required types, while SDK only imports it in AccessibilityModel.
All other files in SDK still refer to the global type.
In follow-up CLs, all pre-existing usages of Protocol will use
the import style.
DISABLE_THIRD_PARTY_CHECK=Updating protocol type format
R=szuend@chromium.org,jacktfranklin@chromium.org
Bug: 1208357
Change-Id: I1d75949b9cd3e37989c6cddf79ac849f5664a1e3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2891756
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Sigurd Schneider
