Psuedo-class selector :text producing errors and incorrect results

[jakejackson1]

Pull Request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

1. If doing ->is(':text') on a text node an error is produced.
2. If doing ->find(':text') it won't match <input /> tags without a type (which are considered text inputs). See https://api.jquery.com/text-selector/

Issue Number: #49

Fixes #49

What is the new behavior?

1. Selectors no longer fatal on non-element nodes

The traverser assumed every node in a match set was a DOMElement and called element-only APIs
(getElementsByTagName(), tagName, getAttribute(), hasAttribute()) on it. A match set can legitimately hold
text, comment, CDATA and processing instruction nodes — contents() produces exactly that — so
$singleTextNode->is(':text') blew up with Call to undefined method DOMText::getElementsByTagName().

The fix is made once, at the boundary those nodes actually enter through. Every non-element reaches the traverser
as part of the initial match set, so initialMatchOnElement(), initialMatchOnID() and
initialMatchOnClasses() skip anything that is not an element. Everything downstream of initialMatch() is
therefore elements, which is why matchesSelector(), matchesSimpleSelector(), combine() and the
match*()/Util::matchesAttribute*() helpers all keep their existing DOMElement type hints — those hints are
the contract, and a caller passing a text node is better served by a TypeError at the boundary than a silent
false from four frames in. The reasoning is documented once, on initialMatch().

initialMatchOnElementNS() needs no guard of its own; it delegates to initialMatchOnElement().

The legacy engine (CSS\QueryPathEventHandler, still used by remove() and replaceAll()) already filtered
non-element nodes out in its constructor, so it needed no crash fix. I verified this rather than assuming it:
remove() was exercised against mixed and non-element-only match sets across the full selector battery on both
main and this branch, with no fatal on either.

2. find('a > b') no longer throws when the left side is the root element

combineDirectDescendant() was the one combinator with no element check — combineAdjacent(),
combineSibling() and combineAnyDescendant() all skip non-elements already. When the left-hand side of a
direct-descendant selector matched the root element, it handed the document to matchesSimpleSelector():

qp('<?xml version="1.0"?><root><a/><b><c/></b></root>', 'root')->find('* > *');
// main: TypeError: matchesSimpleSelector(): Argument #1 ($node) must be of type DOMElement,
//       QueryPath\Document given

This is a pre-existing bug independent of #49 — it needs no text nodes to reproduce — but it is the same class of
fault, so it is fixed here rather than left behind.

3. :text now means what it means in jQuery

:text was implemented as [type="text"], which matched any element carrying that attribute and missed a bare
<input />. It now matches jQuery: an input whose type attribute is absent (text is an input's default
type) or is text, compared case-insensitively. It does not, and never did, indicate whether a node is a text
node.

Both engines share one implementation, CSS\DOMTraverser\Util::isTextInput(), called directly from
PseudoClass::elementMatches() and QueryPathEventHandler::textInput(), so find(':text') and
remove(':text') / replaceAll(':text') cannot drift apart.

Tests

tests/Issues/Issue49Test.php — 7 tests, 91 assertions:

• testCheckingForMatchingTextInputs, testCheckingForEmptyTextInputs — the committed spec from the issue.
• testTextSelectorOnlyMatchesTextInputs — :text matches <input type="text">, bare <input> and
  <input type="TeXt">, and not password / checkbox / submit / <textarea> / <button>.
• testTextSelectorMatchesTheInputItself — the same eight inputs asserted through is() on the input itself.
• testTextSelectorInTheLegacyEngine — remove(':text') selects the same set as find(':text').
• testSelectorsAgainstNonElementNodesDoNotThrow — one fixture holding a text, comment, CDATA and processing
  instruction node as siblings, each run through the same battery of nine is() selectors (element, wildcard,
  class, ID, attribute, attribute-value, :first-child, :text, descendant), five find() selectors, and
  filter('*').
• testMixedNodeMatchSetStillMatchesItsElements — a match set mixing a text node with an element still matches the
  element it holds.

All 7 fail against main (3 errors, 4 failures). Full suite: 394 tests, 1267 assertions, 0 failures
(2 pre-existing skips for create_function on PHP 8). composer run lint and composer run lint:min-php clean.
CI covers PHP 7.1–8.5.

Does this introduce a breaking change?

• Yes
• No

:text changes meaning, deliberately: it no longer matches non-input elements that happen to carry
type="text", and it now matches <input> with no type. This is the point of the issue and brings the selector
in line with jQuery.

Additionally, a wildcard element selector now also considers the context node itself, not only its descendants, so
$el->find('*') includes $el. This is what makes $input->is(':text') true for the input itself, since is()
and filter() are both implemented on top of find() and a bare pseudo-class selector expands to *.

This hunk has a measurable cost and is the part most worth reviewing. Because a null element normalises to
*, it is not confined to a literal find('*') — every attribute-only or pseudo-only selector routes through it.
Measured with the hunk reverted vs. in place, best of 9 runs on a 16,882-node HTML5 document:

query	without	with	delta	result set
find('td')->find('*')	20.83 ms	30.09 ms	+44%	7200 → 14400
find('td')->find('[href]')	21.80 ms	26.60 ms	+22%	2400 → 2400 (identical)
find('td')->find(':text')	27.97 ms	36.78 ms	+31%	2400 → 2400 (identical)
find('tr')->find('em')	9.27 ms	8.26 ms	none	2400 → 2400 (identical)

The [href] and :text rows are the point: 7,200 extra candidates are pushed through the full match pipeline and
every one of them fails, for a result set that is byte-for-byte the same. The last row confirms the cost is
confined to wildcard-subject selectors — a named element is unaffected. Retained memory for
find('td')->find('*') goes from 4.64 MB to 5.11 MB (+10%).

The cost falls entirely on find(), which does not need the behaviour; only is()/filter() do, and there the
candidate set is a single node and the broadening is free. Reverting the hunk fails exactly two assertions, both
is(':text').

Other information

Overlap with #72 and #73. The wildcard self-match above is a workaround for is()/filter() being built on
find(), and both of those PRs address that properly:

• Match selectors against the nodes in hand, not their descendants #72 ("Match selectors against the nodes in hand, not their descendants") gives is()/filter() their own
  notion of matching the current set, which is what this hunk is standing in for.
• Make find() search descendants only, as jQuery does #73 ("Make find() search descendants only, as jQuery does") directly reverts it.

Whichever of those lands after this PR should drop the wildcard self-match from initialMatchOnElement();
testTextSelectorMatchesTheInputItself and testMixedNodeMatchSetStillMatchesItsElements depend on it and move
with it. Nothing else here overlaps: the crash fixes live in the traverser's initial match and combinators, and
:text is a pseudo-class evaluation.

The earlier revision of this description flagged a conflict with #51; that PR no longer exists, and the
assertion it warned about ($q->is(':text') relying on descendant semantics) has since been replaced on this
branch by $q->has(':text'), which is correct under either semantics.

The other jQuery input pseudo-classes (:radio, :checkbox, :password, :submit, :button, …) still use the
old [type=x] implementation and have the same divergence from jQuery in a milder form — they are case-sensitive
and do not check the tag name, so :radio misses <input type="RADIO"> and matches <span type="radio">. Left
alone deliberately: out of scope for #49, and worth its own issue.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.18%. Comparing base (807384f) to head (745a4e2).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main      #50      +/-   ##
============================================
+ Coverage     90.11%   90.18%   +0.06%     
- Complexity     1421     1433      +12     
============================================
  Files            26       26              
  Lines          3198     3219      +21     
============================================
+ Hits           2882     2903      +21     
  Misses          316      316              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.