Use hosted page for finder examples

[Kasturi2004]

Description

Replace the inline HTML fixture in the Finders documentation with Selenium’s hosted locator test page.

Update Finder examples to use real elements from:

https://www.selenium.dev/selenium/web/locators_tests/locators.html

All existing language tabs remain in place.

Motivation and Context

The prior examples referenced an illustrative HTML fragment that could not be executed. Using Selenium’s hosted test page makes the locator examples concrete and runnable against real elements.

Types of changes

• Change to the site (I have double-checked the Netlify deployment, and my changes look good)
• Code example added (and I also added the example to all translated languages)
• Improved translation
• Added new translation (and I also added a notice to each document missing translation)

Checklist

• I have read the [contributing](https://selenium.dev/documentation/en/contributing/) document.
• I have used [hugo](https://gohugo.io/) to render the site/docs locally and I am sure it works.

[netlify]

✅ Deploy Preview for selenium-dev ready!

Name	Link
🔨 Latest commit	db62023
🔍 Latest deploy log	https://app.netlify.com/projects/selenium-dev/deploys/6a99929f25f22e0008792650
😎 Deploy Preview	https://deploy-preview-2776--selenium-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ diemol
❌ Kasturi2004
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[qodo-code-review]

PR Summary by Qodo

Use Selenium hosted locator test page in Finders documentation examples

📝 Documentation 🕐 10-20 Minutes

AI Description

• Replace non-runnable inline HTML fixture with Selenium’s hosted locator test page.
• Update all language tabs to use real, verifiable locators and elements.
• Make Finder examples executable by adding explicit navigation to the test page.

Diagram

graph TD
  A["Finders doc page"] --> B["Language tab examples"] --> C{{"Hosted locator test page"}} --> D["Browser session"]
  B --> E["Real element locators"]
  subgraph Legend
    direction LR
    _doc["Documentation"] ~~~ _ext{{"External hosted page"}} ~~~ _run["Runtime/browser"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep a local HTML fixture in the docs repo

• ➕ No external dependency; examples remain stable offline
• ➕ Changes to test markup can be versioned with documentation
• ➖ More maintenance burden to keep fixture realistic
• ➖ Harder to ensure examples match Selenium-maintained test coverage

2. Mirror the hosted page into the site build output

• ➕ Retains realistic markup while avoiding cross-site dependency
• ➕ Docs can be executed against a same-origin page
• ➖ Adds build/deploy complexity and content duplication
• ➖ Risk of diverging from the canonical Selenium test page

3. Reference language repo snippets (gh-codeblock) only

• ➕ Single source of truth for code examples
• ➕ Enables CI to validate snippets against the target page
• ➖ Harder to keep prose and snippet context tightly aligned
• ➖ Requires ensuring all languages have equivalent snippet coverage

Recommendation: The PR’s approach is good for making docs runnable and concrete, as long as the hosted page is considered a stable contract. If long-term stability/offline use becomes a concern, mirroring the page (or reintroducing a local fixture) is the next best option.

Files changed (1) +132 / -108

Documentation (1) +132 / -108

finders.en.mdSwitch Finders examples to Selenium’s hosted locator test page +132/-108

Switch Finders examples to Selenium’s hosted locator test page

• Removes the illustrative inline HTML snippet and instructs readers to use Selenium’s hosted locator test page. Updates all language-tab examples to navigate to the hosted page and use real locators/elements for single-element, scoped searches, bulk element collection, chained findElements, and active-element attribute retrieval.

website_and_docs/content/documentation/webdriver/elements/finders.en.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📜 Skill insights (0)

1. Removed gh-codeblock finder examples 📘 Rule violation ✧ Quality

Description

The updated Finder examples in finders.en.md were changed to inline code inside tabs (notably
Python and Ruby) instead of using gh-codeblock references to executable code under examples/,
which contradicts the documentation style/contribution guidance and increases the risk that docs
drift from CI-validated runnable examples.

Code

website_and_docs/content/documentation/webdriver/elements/finders.en.md[R36-38]

+  {{< tab header="Python" >}}
+driver.get("https://www.selenium.dev/selenium/web/locators_tests/locators.html")
+first_input = driver.find_element(By.CLASS_NAME, "information")

Evidence

The style and contribution documentation states that code examples should live in the repository’s
examples/ directories and be rendered in docs via the gh-codeblock shortcode so they remain
runnable and kept current through CI. In the updated finders.en.md, the language tabs now contain
inline snippets (e.g., lines showing calls like driver.get(...) and assignments like `first_input
= ...) rather than gh-codeblock` references, demonstrating a direct deviation from the documented
convention and removing the explicit linkage to the examples test suite.

Rule 2141344: Documentation changes must follow the central style guide file
website_and_docs/content/documentation/about/style.en.md[132-143]
website_and_docs/content/documentation/webdriver/elements/finders.en.md[30-47]
website_and_docs/content/documentation/about/contributing.en.md[54-68]
website_and_docs/content/documentation/webdriver/elements/finders.en.md[30-56]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The repo’s documentation guidance (style and contributing) expects code examples to live under `examples/` and be pulled into docs via the `gh-codeblock` shortcode so they are executable, versioned, and CI-validated. The Finder examples in `website_and_docs/content/documentation/webdriver/elements/finders.en.md` were changed from `gh-codeblock` references (notably in Python and Ruby tabs) to inline snippets, increasing the likelihood of documentation drifting from the runnable examples.

## Issue Context
Keeping examples inline in the docs breaks the recommended workflow where documentation snippets are sourced directly from the `examples` test files and can be executed in CI, making updates harder to maintain and easier to get out of sync. Update the underlying example tests to reflect the hosted locator page/updated locators as needed, then restore the docs to reference those files via `gh-codeblock` (using `text=true` where required), ensuring referenced line ranges match the updated example files.

## Fix Focus Areas
- website_and_docs/content/documentation/webdriver/elements/finders.en.md[30-56]
- website_and_docs/content/documentation/webdriver/elements/finders.en.md[33-47]
- website_and_docs/content/documentation/about/style.en.md[132-143]
- website_and_docs/content/documentation/about/contributing.en.md[54-68]
- examples/python/tests/elements/test_finders.py[21-40]
- examples/ruby/spec/elements/finders_spec.rb[8-24]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Input text prints empty 🐞 Bug ≡ Correctness

Description

In “Find Elements From Element”, the example now locates <input> elements but still prints element
text (getText()/text), which is typically empty for inputs, making the runnable example
misleading/no-op output.

Code

website_and_docs/content/documentation/webdriver/elements/finders.en.md[R330-333]

+              // Get all input elements in the form
+              List<WebElement> elements = element.findElements(By.tagName("input"));
              for (WebElement e : elements) {
                  System.out.println(e.getText());

Evidence

The PR changes the child lookup to input elements while leaving the output as getText()/.text.
Elsewhere in the docs, the repo shows input contents should be read via the value attribute.

website_and_docs/content/documentation/webdriver/elements/finders.en.md[322-345]
website_and_docs/content/documentation/webdriver/elements/information.en.md[254-282]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The “Find Elements From Element” examples were changed to locate `<input>` elements, but they still print `getText()`/`.text`, which usually returns an empty string for inputs. This makes the example appear broken even when it successfully finds elements.

### Issue Context
Other docs in this repo demonstrate that the correct way to read what’s in an `<input>` is via the `value` attribute/property.

### Fix Focus Areas
- website_and_docs/content/documentation/webdriver/elements/finders.en.md[330-334]

### Suggested fix
Update the print statement(s) to read the input value instead of text:
- Java: `e.getAttribute("value")`
- Python: `element.get_attribute("value")`
- C#: `e.GetAttribute("value")`
- Ruby: `element.attribute('value')`
- JavaScript: `await e.getAttribute('value')`
- Kotlin: `e.getAttribute("value")`

Alternatively, keep using text output but switch the located elements back to text-bearing elements (e.g., `p`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context

✅ Compliance rules (platform): 10 rules

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Removed gh-codeblock finder examples 📘 Rule violation ✧ Quality

The updated Finder examples in finders.en.md were changed to inline code inside tabs (notably
Python and Ruby) instead of using gh-codeblock references to executable code under examples/,
which contradicts the documentation style/contribution guidance and increases the risk that docs
drift from CI-validated runnable examples.

Agent Prompt

## Issue description
The repo’s documentation guidance (style and contributing) expects code examples to live under `examples/` and be pulled into docs via the `gh-codeblock` shortcode so they are executable, versioned, and CI-validated. The Finder examples in `website_and_docs/content/documentation/webdriver/elements/finders.en.md` were changed from `gh-codeblock` references (notably in Python and Ruby tabs) to inline snippets, increasing the likelihood of documentation drifting from the runnable examples.

## Issue Context
Keeping examples inline in the docs breaks the recommended workflow where documentation snippets are sourced directly from the `examples` test files and can be executed in CI, making updates harder to maintain and easier to get out of sync. Update the underlying example tests to reflect the hosted locator page/updated locators as needed, then restore the docs to reference those files via `gh-codeblock` (using `text=true` where required), ensuring referenced line ranges match the updated example files.

## Fix Focus Areas
- website_and_docs/content/documentation/webdriver/elements/finders.en.md[30-56]
- website_and_docs/content/documentation/webdriver/elements/finders.en.md[33-47]
- website_and_docs/content/documentation/about/style.en.md[132-143]
- website_and_docs/content/documentation/about/contributing.en.md[54-68]
- examples/python/tests/elements/test_finders.py[21-40]
- examples/ruby/spec/elements/finders_spec.rb[8-24]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

2. Input text prints empty 🐞 Bug ≡ Correctness

In “Find Elements From Element”, the example now locates <input> elements but still prints element
text (getText()/text), which is typically empty for inputs, making the runnable example
misleading/no-op output.

Agent Prompt

### Issue description
The “Find Elements From Element” examples were changed to locate `<input>` elements, but they still print `getText()`/`.text`, which usually returns an empty string for inputs. This makes the example appear broken even when it successfully finds elements.

### Issue Context
Other docs in this repo demonstrate that the correct way to read what’s in an `<input>` is via the `value` attribute/property.

### Fix Focus Areas
- website_and_docs/content/documentation/webdriver/elements/finders.en.md[330-334]

### Suggested fix
Update the print statement(s) to read the input value instead of text:
- Java: `e.getAttribute("value")`
- Python: `element.get_attribute("value")`
- C#: `e.GetAttribute("value")`
- Ruby: `element.attribute('value')`
- JavaScript: `await e.getAttribute('value')`
- Kotlin: `e.getAttribute("value")`

Alternatively, keep using text output but switch the located elements back to text-bearing elements (e.g., `p`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[diemol]

Superseeded by #2800