142826 2015-03-18 08:34:17 -0700 Introduce internal.querySelector[All]NoJIT 2015-03-18 11:04:51 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 142703 1 ysuzuki webkit-unassigned benjamin oldest_to_newest 1078195 0 ysuzuki 2015-03-18 08:34:17 -0700 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). 1078196 1 ysuzuki 2015-03-18 08:34:36 -0700 Benjamin, what do you think of? 1078203 2 ysuzuki 2015-03-18 08:45:53 -0700 When landing this change, I'll add non-JIT selector matching tests introduced issue 142703. 1078248 3 benjamin 2015-03-18 11:04:51 -0700 (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.