Bug 142826
| Summary: | Introduce internal.querySelector[All]NoJIT | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | benjamin |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 142703 | ||
| Bug Blocks: | |||
Yusuke Suzuki
Now, almost all selectors (even if it's very complicated) are compiled by CSS JIT.
To maintain non-JIT SelectorChecker and compare CSS JIT results with expected non-JIT results,
I propose new internal.API, internal.querySelectorNoJIT(root, selector) and internal.querySelectorAllNoJIT(root, selector).
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Yusuke Suzuki
Benjamin, what do you think of?
Yusuke Suzuki
When landing this change, I'll add non-JIT selector matching tests introduced issue 142703.
Benjamin Poulain
(In reply to comment #2)
> When landing this change, I'll add non-JIT selector matching tests
> introduced issue 142703.
I agree the non-JIT cases are under-tested, that has been worrying me for a while.
I have been thinking about some solutions:
-Add a new pseudo class :-webkit-no-jit that fails to compile. The problem with this is someone could ship it by accident.
-Change the test running such that the layout tests in fast/selectors are run twice: once with the normal setup, then a second time with all JIT disabled (which we can do at runtime since we rely on the same flags as JavaScriptCore). I think this would have the most value.
I am okay with internal.querySelectorNoJIT(root, selector) and internal.querySelectorAllNoJIT(root, selector). That seems useful.