Now the server can serve from the tests directory, it will sometimes get
two requests for the same file, one prefixed with front_end and the
other not. If that happens the server now redirects the request such
that we only ever serve each file once and the browser doesn't
double-execute a module.
Change-Id: I14b44aad8b16d1c3f2f787082c70532a8f8776e9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2599746
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Most of the time we won't need this fully fledged environment, but for
some things (such as context menus, guess what I'm working on right now
:D) we do need a faked out environment to enable these features to run
when we run the component in isolation in the component docs.
Note: while this CL contains no component docs changes that take
advantage of it, I've tested locally with context menus in the data grid
and this change does work.
Fixed: 1148323
Change-Id: Ic8c508840a20b6d0f0e72fd7019a16271f04bea6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2597313
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This CL provides a script that generates a dark mode stylesheet for a
given sheet, just like the runtime color patching (in fact, it uses the
same code!).
The script loads up the given CSS file, imports `ThemeSupport`, and
patches it. It then takes the final CSS file and prefixes
`:host-context(.-theme-with-dark-background)` to each selector. We can
then load the lightmode and the dark mode stylesheet into DevTools.
This is non ideal because we end up loading two stylesheets, but the
alternative is to maintain the runtime color patching for ever, or
update all third party stylesheets to use our CSS variables, which is a
lot of work.
The script does rely on the hosted mode server running but I think this
is reasonable; it's only going to be run rarely on a few CSS files, so
we won't be running it automatically on CI or anything so we can keep
the process fairly manual.
Bug: 1152736
Change-Id: I707c53fbccb3e03c9fac6691f40df32bcdb17c1f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2587024
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
If you're in the front_end directory and you mistakenly include
front_end in an import, e.g:
import * as UI from '../../front_end/ui/ui.js';
instead of:
import * as UI from '../ui/ui.js';
It will cause problems in a release build. This CL lands an ESLint rule
to ban these, but still allows it for unit tests.
Fixed: 1157057
Change-Id: Ia49279794616568f9e88241152e3412fcd9a8b36
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2581547
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
On the bots these tests will run in out/Release but the component server
logic for figuring out the path to the gen directory was wrong; it
navigated up from its position into the root dir, and then back in to
`out/TARGET`. Rather than do that, we instead just walk up from the
scripts dir until we end up in the out/TARGET directory. That way
regardless of if we run in out/Default or out/Release, the script will
find the right directory.
Bug: 1153281
Change-Id: I1d369e47b9931ade60bc86ff52aea7105f10cefd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2575086
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
depot_tools ships a "vpython" binary that is added to the $PATH
for all Chromium engineers. This binary is versioned by depot_tools
which we roll in ourselves as part of `gclient sync`.
By using `vpython` instead of `python`, we are no longer depended
on the Python version installed locally and instead use the version
we pull in from DEPS.
R=liviurau@chromium.org
Change-Id: If49a54c24b6cf129ff843cd9ca1140a723a78afb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2571462
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Both front_end_devtools_module_entrypoint_sources and
generated_devtools_module_entrypoint_sources were unused, since
the `devtools_entrypoint` migration has finished.
Secondly, we can rename generated_typescript_entrypoint_sources to
generated_module_entrypoint_sources, since we no longer need to
distinguish between JavaScript and TypeScript entrypoints.
Lastly, we can clean up the definition of
devtools_module_entrypoint_sources to no longer include the
$resources_out_dir line, which saves some duplication.
R=aerotwist@chromium.org
Change-Id: I1a327cf40cec6630b3be7ac53e2c87f7e179c895
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2566802
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>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This CL introduces the infrastructure and first test for what we're calling
"Interaction tests". These are tests that can be used to test component
behaviour that cannot be tested via Karma unit tests but don't require an e2e
test either.
The best example here is complex user interactions: clicking and dragging a
mouse, or doing multiple tabs to navigate through the UI.
Note that the one interaction test added here for theme_colors isn't the best
example of a complex test, but it's a test that's good enough for now whilst we
get everything set up on infrastructure and make sure it runs without flaking.
Bug: 1153281
Change-Id: Ifb37639a557c459974f703b8954ae68a93d5d368
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2566808
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
As part of the work to enable Puppeteer component tests, we need to
configure the test suite to run either the hosted mode server or the
component docs server. This CL updates it to take a flag, and makes some
updates to the component docs server, which now has to run either
directly or in the out/Default/gen directory depending on how it is run.
I suspect I'll make a follow up CL to always run the component server in
out/Default/gen, but for now enabling it to detect its context is the
quickest way to unblock running it in tests. The next CL will add a
component test suite that can run a basic test against the component doc
server, but I have manually verified locally that I can run tests
against that server.
Bug: 1153281
Change-Id: I55bda4edd0a983d03bfecff0446b0f3e3a008b52
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562707
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
To date the Karma singleRun option has been set based on whether the
developer sets the DEBUG environment variable. This CL adds support for
an additional REPEAT environment variable, such that someone can run
multiple, non-debug (i.e., headless) test runs.
In order to make this more convenient, this CL also improves the watcher
script (`npm run watch`) such that it restarts autoninja whenever files
are changed.
Therefore a developer can now run:
`REPEAT=1 npm run auto-unittest` and `npm run watch` in conjunction, and
have the code be recompiled automatically, and the unit tests
(re)started.
R=jacktfranklin@chromium.org
Change-Id: I8cff9eb7d223a5325e952413ddd5c1f55dd8aec2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562709
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
This rule enforces that within a LitHtml template when we bind to the
`.data=` property we provide an explicit type cast that must be a type
reference.
This is one of the checks that the component bridges used to make, but
now we need to port them to ESLint rules.
Bug: 1130536
Change-Id: I401661289a829fd181bf91943fffe162b87de8b8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562345
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL updates the component docs server so it automatically injects the new
colour variables (which are part of the dark mode work) into the server. It
contains the following changes:
1. Pulling out the new colours into a new CSS file,
`ui/themeColors.css`, which contain all the new definitions.
2. Injecting that new file where we inject `inspectorStyles.css`
currently.
3. Updating the component docs server to intercept any requests to load
an HTML example file, read the HTML contents and inject a `<style>`
tag to load in the theme colours.
4. Additionally we now provide a small bit of JS that adds a handy
button to toggle light/dark mode without needing to dive into the dev
tools.
Fixed: 1152774
Change-Id: Ia2df0e00315dfeb532570ea5634fa54677337f76
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2560941
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Jan Scheffler