search

w3c / webdriver-bidi

Bidirectional WebDriver protocol for browser automation
https://w3c.github.io/webdriver-bidi/
363 stars 40 forks source link

Inconsistency in "inner text" locator #612

Open jugglinmike opened 10 months ago

jugglinmike commented 10 months ago

Given the following markup:

<p><span>a</span><span>b</span></p>

...the "inner text" locator strategy will report a partial match of the string "ab" by returning the <p> element. This seems appropriate, but the behavior for a similar input seems somewhat contrary. Given the following markup:

<p><span>a</span><span>b</span><span>ab</span></p>

...the "inner text" locator strategy will report a partial match of the string "ab" by returning only the final <span> element. Is this intentional?

(The algorithm step which defines this behavior currently has an unrelated bug, and I'm wondering whether or not to preserve this behavior in a patch to fix that other bug.)

jimevans commented 10 months ago

@jugglinmike Yes, the behavior is intentional. Matching on innerText should find the “deepest” element in the context node’s tree that matches, subject to the maxDepth setting. The alternative would be to return the deepest <span> and the parent <p> elements, and indeed, every parent element in the tree all the way up to <body>, which would be confusing, at least to me. Indeed, the behavior should be modeled on the Puppeteer pseudoselector for matching on text. If I’ve got it wrong, or you feel there should be changes short of removing the innerText strategy altogether (which is a proverbial hill I’m wllling to die on), I’d love to hear suggestions.

jugglinmike commented 10 months ago

That design seems sound to me. The issue I'm reporting is the algorithm's inability to recognize a distinct match (given the intent to return all matches).

By my reading, the algorithm is intended to recognize when a match occurs across multiple nodes, and it's intended to report such matches by returning the nodes' common ancestor. This is the first example in my original report.

The second example describes a case where there is an inter-node match whose common ancestor also contains an unrelated match. I expect that to return the <p> element (along with the final <span>) not because the <p> is a parent of the final <span> but because the <p> is a common ancestor of the <span> elements which match only when considered together.

Put another way, it seems inconsistent for the algorithm to disqualify the <p> only because another node matches.