This CL adds the trust token operation result to NetworkRequest and
forwards the data to the Trust Token tab in the Network panel.
As the operation result can arrive after the report was initially
rendered, this CL adds a new event to trigger a re-render as
necessary.
The CL doesn't yet add the rendering for the result itself, just
prepares the component to have the necessary data.
R=jacktfranklin@chromium.org
Bug: chromium:1126824
Change-Id: I9c6c080de9268219cd8b4b12804a7ca7c4de39a8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2567783
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
This fixes a bug where on an empty build `npm run auto-unittest` would fail with errors about loading CSS files. There were two problems:
- in the build graph, the unit tests did not have an explicit dep to the
legacy_css group
- the legacy_css group was missing some deps itself, so some modules did
not have their CSS put into the right place.
Fixed: 1153625
Change-Id: Ib08f14a3d61ee0e55e492cc824ddf806d751e787
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2567116
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
When debug evaluation hits exceptions in wasm debugging, the
LanguagePluginManager incorrectly propagated those errors, causing weird
warnings in the wrong places or warnings that are missing altogether.
This CL hooks up the plugin manager with the existing error reporting
mechanisms and includes a test to make sure the errors show up.
Drive-by: In the watch window, when evaluation failed, we previously
swallowed the actual exception. That's probably because most of the time
that exception is a reference error because variables aren't valid in
the current scope. This CL adds a tooltip that shows the exception.
Bug: chromium:1137514, chromium:1153315
Change-Id: Ia1ec81ce95598adf7abab8c4e31c3310e3669fb7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2565376
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
The Device Orientation emulation code had a few bugs since its
introduction at the end of 2013 and the redesign from 2016:
1. Angles outside the intervals allowed by the Device Orientation spec
were allowed and could be entered or produced by dragging the phone
model. These invalid angels were also reported to API users.
2. Some of the presets also used angles outside valid intervals.
3. Gamma in the CSS transformation used to rotate the phone model was
wrong. It depended on the value of beta, and was essentially always
rotating around the original Y axis in the Device Orientation
coordinate space, which is parallel to the fixed Z axis in the CSS
coordinate space. This means that if some angles were entered in the
input boxes, the rotation produced on the phone model could be
completely different from what it should correspond to.
4. All of the above together led to situations such as:
a. Load the (wrong) landscape left preset
b. Shift-drag to the left to see the values suddenly go from
alpha=0, beta=90, gamma=-90 to e.g. alpha=-180, beta=-90 and
gamma=-89.6.
There are a few causes for these, mostly caused by the fact that the
CSS and Device Orientation coordinate systems differ:
- The CSS coordinate system is left-handed, X and Y are parallel to the
screen (X is positive to the right and Y is positive to the bottom),
and Z is perpendicular to the screen (positive towards the viewer).
- The Device Orientation coordinate system is right-handed, X and Y are
parallel to the screen (X is positive to the right and Y is positive
to the top), and Z is perpendicular to the screen (positive towards
the viewer).
- Additionally, the phone model is rotated +90 degrees in the X axis in
the CSS coordinate system (i.e. with alpha=0, beta=0, gamma=0 we are
looking at the bottom of the phone, not its screen), which further
complicates the transformations we have to do.
The explanations about what fixes are being landed in this CL are
almost bigger than the changes themselves:
- Add further validation to the Euler angles allowed in the UI. Per the
Device Orientation spec, alpha must be in the [0, 360) degrees
interval, beta must be in the [-180, 180) degrees interval and gamma
must be in the [-90, 90) degrees interval.
- Fix the angles used in the preset orientations so that they are all
within the ranges allowed by the spec.
- Rework the UI.Geometry.EulerAngles class:
* Remove the toRotate3DString() method. The transformation it
generates is very specific to the layout used in SensorsView and is
easily represented by a simpler and more correct sequence of CSS
transformations in SensorsView directly.
* Rewrite the rotation matrix -> Euler angle calculations. The
previous code only worked with the Z-Y'-X'' rotations we used to do
in _setBoxOrientation(), and it led to some of the bugs outlined
above. The new code is imported from Chromium
itself (orientation_util.cc at commit 1be837b6f142). It expects a
rotation matrix with operations performed in the right (Z-X'-Y'')
order, returns angles within the ranges allowed by the spec and
handles Gimbal locks (which happen when beta=+90 or -90 degrees).
The method has been renamed to better indicate that it handles one
specific type of rotation matrix.
- Replace the DOMMatrix.rotate() call with separate rotations around
the Z, X and Y axes in the right order. CSS operations such as the
rotate() transformation follow a Z-Y'-X'' order that leads to a
different rotation from what we expect from a Device Orientation
perspective.
- Most importantly, document all the math we are doing here more
thoroughly so that the next person working on this code does not get
lost in it :-)
The new code does have a few caveats:
1. Angle canonicalization can cause entering some angles and then
dragging the phone model to produce very different angles. For
example:
a. Entering 45/90/45 and dragging will automatically avoid a Gimbal
lock and result in 90/90/0 (plus the change caused by dragging).
b. Entering 0/0/89 and shift-dragging to the left will cause the
angles to become 180/-180/-89 (plus whatever extra change caused
by dragging).
2. Like the old code, the rotation matrix -> Euler algorithm includes
floating-point math. Very large rotations will produce a lot of
imprecision (e.g. 360 * 20000000000), but angles in the ranges we
use (i.e. around the allowed intervals) are handled very well.
3. The "Shift+drag to rotate around the y-axis" hint text only made
sense in the buggy code, when changing gamma like this feature did
always rotated around the original Y axis. The behavior has been
preserved though, as it felt intuitive in configurations like the
preset orientation ones. It can look a bit odd with other angles
though.
Bug: chromium:1137281
Change-Id: I461d2fa237f33fb7b5e240a6376f24f126ccd317
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562673
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
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>
Currently the devtools-frontend doesn't really distinguish between
UI locations that point to the first column (represented as column
number 0) and UI locations that refer to the whole line, and somehow
we managed to get away with this mixed state. But for the language
plugins to really provide a consistent stepping / breakpoint experience
we need to preserve the information of whether a location refers to the
whole line or to the first column.
The communication to the language plugin continues to pass numbers
for backwards compatibility, using `-1` to state the absence of
column information (i.e. indicating that the location refers to the
line as a whole).
Also-By: pfaffe@chromium.org
Bug: chromium:1153123, chromium:1055327
Change-Id: I030da16e34ac02c259bfd9539e50b77ca18347db
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562350
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Some logic requires the state of both the flex and
grid highlighters (setShowViewportSizeOnResize) so it
makes sense to combine the implementation in one class
given they are very similar. Additionally:
- extracted the new class into a separate file.
- added a basic unit test.
- enabled colors for flex containers.
Bug: 1150294
Change-Id: I84ae3dddcc758a3a55f849fa668c30c90e6075b3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2560749
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Patrick Brosset <patrick.brosset@microsoft.com>
This CL creates a new <devtools-linkifier> component that will eventually
replace the legacy linkifier code.
For now this component only supports taking a string URL, but in time (and as we
need) we can extend it to support all the inputs that the legacy Linkifier code
uses.
It works by emitting an event that is picked up by the legacy linkifier and
threaded through the legacy system.
Bug: 1149403
Change-Id: I76023052d818ab0f296db887fb03d6761ca4796b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2558297
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Alfonso Castaño <alcastano@google.com>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
`TextUtils.FilterParser` is commonly used to parse user input into a
series of filters. This CL updates the new data-grid-controller so it
can take the result of parsing user input into an array of parsed
filters. This means we can hook it up to existing input boxes in
DevTools and unblocks us landing the new data grid into the protocol
monitor.
Bug: 1125968
Change-Id: I45896796d7e7cc720d22c48b65325fb099115da8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2560237
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This cl changes the default behaviour of removing all cookies that are
somehow related to the current page when clicking the "Clear site data"
button in the Storage tab of the Application panel. This lead to people
unexpectedly removing their session cookies on third party websites like
Google or Facebook when resources from them were included in the page.
To go back to the previous behaviour, this cl adds a checkbox next to
the button to also clear 3rd party cookies.
Screenshot: https://imgur.com/a/2PCz2gi
Bug:chromium:1012337
Change-Id: I171a6e3e07d56d5cbeafb0b2b030e3a5e24aad3b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2537954
Commit-Queue: Jan Scheffler <janscheffler@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Jack Franklin
