Skip to content

Document adoptContext for JavaScript extensions - #21

Open
d-biehl wants to merge 9 commits into
MarketSquare:mainfrom
d-biehl:adopt-context
Open

d-biehl wants to merge 9 commits into
MarketSquare:mainfrom
d-biehl:adopt-context

Conversation

@d-biehl

@d-biehl d-biehl commented Oct 9, 2026 •

Copy link
Copy Markdown

Documents adoptContext from MarketSquare/robotframework-browser#5318 on the JavaScript extensions page. The code is planned for Browser 20.7.0, so please merge this together with that release.

  • The names Browser fills in: the table gets adoptContext.
  • New section "Handing over a context you created": an Electron example, what adoptContext registers and returns, how the context is closed, and when onClose runs. A note says that Browser itself does not support Electron or Android.
  • "Which extension point?": the table gets a row for platforms that Browser does not launch.
  • Correction in "Custom selector strategies":
    • The warning said that every JavaScript extension keyword needs an open browser and fails with Browser has been closed.
    • Since 20.4.0, only keywords that take page, context or browser need one, and the message is No Browser is open but needed for this operation.
    • The new section relies on this, so the page now states it once below the table of names. The example's comment is removed.
    • I ran the selector example both ways against Browser 20.6.0, registering before and after New Browser. The selector worked in both.

The :since marker says 20.7.0, the milestone that is open now. pnpm verify passes.

The section "From a library written in Python" describes adopted_context_options, register_adopted_context and AdoptedContextOptions from MarketSquare/robotframework-browser#5326, so this PR should not be merged before that one. pnpm verify still passes.

AI / tooling disclosure
This contribution was prepared with assistance from Claude Code (Anthropic). I reviewed the result manually, understand the changes, verified them locally, and confirm that I have the right to submit this contribution under the project license.

Documents adoptContext from MarketSquare/robotframework-browser#5318, planned for Browser 20.7.0. The custom selector warning is corrected: since 20.4.0, only keywords that take page, context or browser need an open browser.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The documented return shape incorrectly guarantees pageId for contexts without an existing page.

1 open finding
What changed in this PR

Documents the upcoming adoptContext JavaScript extension API and corrects browser-state requirements.

Changes:

  • Adds adoptContext usage and lifecycle guidance.
  • Updates injected-argument and extension-point tables.
  • Corrects custom-selector prerequisites.
File Description
content/​docs/​extending/​javascript-extensions.md Documents context adoption and updates extension guidance.

🧠 Review effort: Balanced


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread content/docs/extending/javascript-extensions.md Outdated
adoptContext takes the optional name, headless and onClose, and an adopted context gets Browser's timeout. The concepts page names adopted contexts among the browsers that close together with their context.
adoptContext no longer sets the library timeout. Extension functions can request defaultTimeout like the other injected names and set it on the context they adopt; the Electron example does so.
Browser passes the tracing option to Node as given, so a relative path would be relative to the Node process, not to the output directory.
A library written in Python gets the tracing and recording options of an adopted context from adopted_context_options and registers the context with register_adopted_context.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The Python integration example is not callable as shown, its JavaScript function is not exported, and several documentation inconsistencies remain.

2 open findings
1 resolved since last review

🧠 Review effort: Balanced

Comment thread content/docs/extending/javascript-extensions.md Outdated
Comment thread content/docs/extending/javascript-extensions.md Outdated
The method of the example library is decorated with @Keyword, so that Robot Framework sees it, and the JavaScript module exports its function. The summary counts the seven names that Browser fills in.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The examples need type conversion and failure cleanup fixes to avoid invalid options and leaked Electron processes.

1 open finding
2 resolved since last review
Previously missed (1)

In code that hasn't changed since last review

Medium severity Clean up Electron process when launch or adoption fails

content/​docs/​extending/​javascript-extensions.md:156

If waiting for the first window or adopting the context fails, this launched Electron process is never handed to Browser and therefore cannot be cleaned up by Close Browser or automatic closing. Close the application on this error path (and kill it if graceful close fails) so a failed launch keyword does not leak a process.

This issue also appears on line 239 of the same file.

🧠 Review effort: Balanced

Comment thread content/docs/extending/javascript-extensions.md
…d launch

The Python example types its arguments with Browser's types, so that Robot Framework converts them as for New Context. A note says that a real module closes the application when anything after the launch fails.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

The Python example does not initialize its JavaScript module, so its documented keyword call fails.

0 open findings

1 resolved since last review
Previously missed (1)

In code that hasn't changed since last review

Medium severity Register electron.js before invoking launchElectronApplication

content/​docs/​extending/​javascript-extensions.md:231

The subclass never registers electron.js, so call_js_keyword("launchElectronApplication", ...) has no Node-side function to invoke and this Python-library example fails as shown. Initialize the module in the subclass before calling it; using init_js_extension also avoids exposing a second Robot keyword with the same name as this wrapper.

🧠 Review effort: Balanced

@d-biehl

d-biehl commented Oct 11, 2026

Copy link
Copy Markdown
Author

About the note in the last review that the Python example never loads electron.js: the page shows two ways to do the same thing, a JavaScript extension loaded with jsextension and a library written in Python. Each example shows only its own part, so the Python one leaves out how the library loads its module, for example with init_js_extension. I left it as it is.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants