[javascript] Migrate find-elements atom from Closure to TypeScript#17458
Merged
Conversation
Replace the Google Closure `bot.locators.findElements` fragment with a self-contained TypeScript implementation, following the same pattern used for `get-attribute` and `is-displayed`. New files: - javascript/atoms/typescript/find-elements.ts — IIFE implementing all locator strategies: css selector, id, class name, tag name, link text, partial link text, name, xpath, and the full relative locator (above/below/left/right/near and straight-* variants with proximity sort) - javascript/atoms/typescript/wrap-find-elements-as-global.js — wraps compiled output as window.bot.locators.typescript.findElements - javascript/atoms/test/find_elements_typescript_test.html — QUnit browser tests covering all strategies (18 tests) Build changes: - javascript/atoms/BUILD.bazel: add tsc compile, strip-semicolon, and global-wrap targets; include find-elements-global in atoms filegroup - javascript/atoms/fragments/BUILD.bazel: add copy_file target find-elements-typescript with same visibility as the old closure fragment - py/BUILD.bazel: switch find-elements src to the TypeScript-generated file The relative_by_tests-chrome-bidi integration tests pass with the new implementation.
…ashes in className selector CodeQL flagged two incomplete string escaping issues: 1. cssEscapeId used '\\' replacement string which CodeQL cannot statically verify handles backslash input. Switch to a replacement function (c) => '\\' + c to make the intent explicit. 2. classNameMany escaped dots in class names but not backslashes first, which means a class name like 'foo\\bar' would produce '.foo\\bar' where '\\b' is misinterpreted as a CSS backspace escape. Fix by escaping backslashes before escaping dots.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
bot.locators.findElementsfragment (//javascript/atoms/fragments:find-elements.js) with a self-contained TypeScript IIFE, following the same pattern asget-attributeandis-displayedpy/BUILD.bazelto consume the new TypeScript-generated file instead of the Closure outputWhat changed
New files:
javascript/atoms/typescript/find-elements.ts— TypeScript IIFE that implements all locator strategies without any Closure or external dependencies:css selector,id,class name,tag name,link text,partial link text,name,xpath, and the fullrelativelocator (above/below/left/right/near and straight-* variants with proximity sort matching the Closure original)javascript/atoms/typescript/wrap-find-elements-as-global.js— Node script that wraps compiled output aswindow.bot.locators.typescript.findElementsfor browser test pagesjavascript/atoms/test/find_elements_typescript_test.html— 18 QUnit tests exercising each strategy in a real browser via the existingclosure_test_suiteinfrastructureUpdated files:
javascript/atoms/BUILD.bazel— tsc compile, strip-semicolon, global-wrap targets;find-elements-globaladded to theatomsfilegroupjavascript/atoms/fragments/BUILD.bazel—copy_filetargetfind-elements-typescriptwith same visibility as the old Closure fragmentpy/BUILD.bazel—find-elementscopy_file src switched fromfind-elements.jstofind-elements-typescript.jsTesting
//py:test/selenium/webdriver/support/relative_by_tests-chrome-bidi— PASSED (this is the primary consumer offindElementsin Python; it exercises all relative locator directions including near, above, below, left, right, straight-* variants)bazel build //javascript/atoms:find-elements-typescript-generatedwindow_testsandapi_example_testsare window-position assertions that fail on multi-monitor macOS setups; they are not affected by this changeNotes for reviewers
The
findElementsatom is used by Python (and Java/Ruby/dotnet — unchanged here) exclusively forRelativeBylocators. The calling convention from Python is:WebElement references in
argsare deserialized to actual DOMElementobjects by the browser before the script runs, matching the behaviour expected by theresolveAnchorfunction.