Skip to content

Commit a11a5d9

Browse files
authored
Navigate to about:blank after loading a crashtest (#193)
This helps catch a class of delayed crashes that are currently difficult to attribute to a specific test and so difficult to provide correct metadata for.
1 parent 81c23e7 commit a11a5d9

File tree

1 file changed

+41
-0
lines changed

1 file changed

+41
-0
lines changed

rfcs/crash_test_navigate.md

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
# RFC 193: Navigate after Crash Tests
2+
3+
## Summary
4+
5+
Navigate to about:blank after successfully loading the test URL in
6+
crash tests.
7+
8+
## Details
9+
10+
Add a step to the end of crash tests where the browsing context that
11+
loaded the test is navigated to about:blank.
12+
13+
This is because we have seen cases where the crash the test is trying
14+
to detect doesn't happen until a subsequent navigation. That kind of
15+
crash is hard to handle in web-platform-tests: if the test happens to
16+
be the last one in a group it may be missed entirely, and because we
17+
want to make it possible to import tests without blocking on fixing
18+
the bugs they reveal, it's important to be able to annotate a crash as
19+
related to a specific test so the expectation metadata can be set
20+
correctly; if the actual crash happens at the start of the following
21+
test this doesn't work because we've already recorded an incorrect
22+
PASS status for the previous test. It's also helpful for humans to see
23+
the test that's actually failing when debugging the problem.
24+
25+
## Risks
26+
27+
This will decrease the performance of crash tests. However since
28+
they're few in number and generally fast compared to other test types,
29+
this seems like an acceptable tradeoff.
30+
31+
Since about:blank is a special URL it's possible that navigating to
32+
that is triggering different codepaths to navigating to an actual
33+
server-provided resource. We could fix this by navigating to a blank
34+
page on the server, but this would likely have even worse performance
35+
implications. We should consider this option if we find there are
36+
cases not caught by this approach that would be caught when navigating
37+
to a http URL.
38+
39+
This won't cover all possible cases of delayed crashes; in general
40+
that's an impossible problem to solve. However it is an incremental
41+
improvement over the status quo.

0 commit comments

Comments
 (0)