This reverts commit 1b596f3b4b.
Reason for revert: closed the tree, more blink tests to adapt
Original change's description:
> Enable synchronization on instrumentation breakpoints
>
> This CL introduces the synchronization point for setting
> breakpoints on new scripts using instrumentation breakpoints.
>
> Instrumentation breakpoints will trigger at the first statement
> of a newly run script. Afterwards we wait for all resources
> that we need to set a breakpoint (if one is cached for that
> particular script), set it, and resume.
>
> Note: this will not correctly synchronize the case where we
> just opened DevTools or just created a new target, as at this
> point some scripts might have started running. For this, we
> need to synchronize the Debugger.enable call, which is something
> that is left to take care of.
>
> Bug: chromium:1229541, chromium:1133307, chromium:1300509
> Change-Id: I44e9b053a7cf64cc1f477a68ce9389cd92a1d05d
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3470237
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Bug: chromium:1229541, chromium:1133307, chromium:1300509
Change-Id: I9eccdf065820854746ec7ad4643362859c9960e4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3506653
Auto-Submit: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Johan Bay <jobay@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Owners-Override: Kim-Anh Tran <kimanh@chromium.org>
This CL introduces the synchronization point for setting
breakpoints on new scripts using instrumentation breakpoints.
Instrumentation breakpoints will trigger at the first statement
of a newly run script. Afterwards we wait for all resources
that we need to set a breakpoint (if one is cached for that
particular script), set it, and resume.
Note: this will not correctly synchronize the case where we
just opened DevTools or just created a new target, as at this
point some scripts might have started running. For this, we
need to synchronize the Debugger.enable call, which is something
that is left to take care of.
Bug: chromium:1229541, chromium:1133307, chromium:1300509
Change-Id: I44e9b053a7cf64cc1f477a68ce9389cd92a1d05d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3470237
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
I know that upping the timeout isn't always the most reliable fix but in
this case locally I was able to replicate the failures until I upped the
timeout this high. The UI that these tests cover is slow and has a lot
of data involved so I'm not surprised that they take such a long time on
the bots.
Bug: 1239550
Change-Id: I62a8065e8d66da9190554cfec3a89a34790babf7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3099990
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
`assertNotNull()` of `undefined` does not cause the test to fail,
whereas `assertNotNullOrUndefined()` does.
Because of import restrictions, platform.js's
`assertNotNullOrUndefined()` is copied to helper.ts.
Bug: 1072335
Change-Id: Iaa56492c2f58f735cb93b434f6a73c65cdb740c5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3057046
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Wolfgang Beyer <wolfi@chromium.org>
Change test that ensures that "Pending activities" are present.
Before this CL, we would test that a root group "Pending activities"
exists which contains the actual pending activities, e.g. MediaQueryList
in the test.
After the CL, we ensure a different graph where a that a regular object
named "Pending activities" retains the pending activities. In addition,
we test the the object retains the activities via some intermediate
backing store represented as InternalNode.
Blink dependency: https://crrev.com/c/2954763
Follow up removing old behavior: https://crrev.com/c/2960454
Bug: chromium:1056170
Change-Id: I1cfd3c13c55ca2d4c29056fdb2ac9fabbcbbc0bb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2956328
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
I was able to recreate this reliably on my Mac machine by upping the CPU
throttling. I added all the `steps` in such that I could see where it
failed and it always failed waiting for the retainer chain.
I then ran `it.repeat(50, ...)` with a timeout of 40,000ms and that
passed. I lowered it to 30,000 and about 90% of the tests passed, but
the odd one flaked. Therefore 35,000 seems the sweet spot.
I'd love to fix this "better" but there didn't seem to be an obvious
problem beyond this test taking time to run due to the nature of the
heap snapshot and how intensive it is to render and update.
Fixed: 1134093
Change-Id: Ibd160518b03067d7cda3077f2136f0ee1ff887a4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2443624
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL fixes a problem where Window names retainer chains
were not consistenly reported across platforms. In particular,
some windows will be called 'Window /' on one platform, but
only 'Window' on other platforms (occassionally).
This CL normalizes window names further to just "Window".
Bug: chromium:1110817
Change-Id: Ie37a4a627bde55b58ff7964701754ac987c081fb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2412329
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
The heap snapshot UI is large and renders a lot of data. When running
the tests locally with `STRESS=1` (to emulate slower bots vs my MacBook)
they routinely fail. Upping the timeout to 15 seconds eliminates the
failure (tested via multiple `it.repeat` runs). I also tested a 10
second timeout, but that wasn't long enough.
Bug: 1110817
Change-Id: I88d44e5e7a3c6119cdf9b28b1774ebc102439ea4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2410220
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
`waitForFunction` previously always waited 100 ms before checking if
the given function is truthy. We can improve the total e2e test suite
running time by 40-50 s by eliminating this timeout. This,
unfortunately, makes some of the tests flake since they relied on this
timeout. This CL attempts to eliminate the timeout and patch the tests
that relied on it. In the cases where a test could not be patched the
timeout is inserted in the test explicitly.
Local experiments showed that this CL reduces the total runtime from
on avg. ~309 seconds to an avg. of ~264 seconds.
This amounts to a ~45 second reduction or ~15%.
This is a reland of a26e3406c7
which was a reland of 3be2087f9d
Bug: 1112692
Change-Id: I3a5156d35553415bfbac95c0251b849ed77f4767
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2354096
Commit-Queue: Johan Bay <jobay@google.com>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
`waitForFunction` previously always waited 100 ms before checking if
the given function is truthy. We can improve the total e2e test suite
running time by 40-50 s by eliminating this timeout. This,
unfortunately, makes some of the tests flake since they relied on this
timeout. This CL attempts to eliminate the timeout and patch the tests
that relied on it. In the cases where a test could not be patched the
timeout is inserted in the test explicitly.
Local experiments showed that this CL reduces the total runtime from
on avg. 5:05 minutes to an avg. of 4:19 minutes.
This amounts to a ~46 s reduction or ~15%.
This is a reland of 3be2087f9d
Bug: 1112692
Change-Id: Id92542de85920f95bb922d1b62ddfb63b83a055a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2346366
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Johan Bay <jobay@google.com>
This introduces a new goToResource shared helper for all e2e puppeteer
tests to use.
It helps simplify a bunch of tests and other helpers in that they don't
need to replicate the `${resourcesPath}/some/file.html` part.
Because this helper also knows how to get hold of the target on its own
it also further simplifies other tests that don't need to import it
anymore.
The next step would be to create a shared helper that knows how to
navigate to panels inside the DevTools front-end as this is also
duplicated across tests.
Bug: 1091226
Change-Id: I717455a51dec30e153d796ef101eab3d42bc2da1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2230320
Commit-Queue: Patrick Brosset <patrick.brosset@microsoft.com>
Reviewed-by: Jan Scheffler <janscheffler@chromium.org>
Reviewed-by: Jose Leal <joselea@microsoft.com>
Jack Franklin