Issue 12549 fix atoms generation lowdash

[ahalbrock]

User description

Thanks for contributing to Selenium!
A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines.
Avoid large PRs, help reviewers by making them as simple and short as possible.

Motivation and Context

The selenium atoms are used as part of the XCUITest iOS driver that is used in Appium, more specifically through appium-remote-debugger. The way they are currently generated is not working because of 2 issues, one where the window object passed in is not actually window, so it is missing some objects / properties that some atoms are expecting. The other issue is if window is actually used, it ends up overwriting "window._", causing projects that use lodash or underscore to break under automation.

This fix brings back using window itself, but also changes the exported function symbol to be something else so that "_" is not overwritten.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

Updated javascript/private/fragment.bzl file to use a new exported function name and also changed the wrapper to pass in window instead of just pieces of it. There is already a test added to verify injection of atoms clobbers "_" (selenium\java\test\org\openqa\selenium\AtomsInjectionTest.java), so I have not created any additional tests for this.

---

PR Type

Bug fix

---

Description

• Fixed issue with atoms generation overwriting window._.

• Introduced EXPORT_FUNCTION_NAME to avoid conflicts with lodash/underscore.

• Updated wrapper to pass the entire window object for better compatibility.

---

Changes walkthrough 📝

	Relevant files
Bug fix	fragment.bzl Refactored atoms export to avoid `window._` conflicts        javascript/private/fragment.bzl Added EXPORT_FUNCTION_NAME to define a unique exported function name. Updated goog.exportSymbol to use EXPORT_FUNCTION_NAME. Modified wrapper to apply the entire window object. +5/-6

---

Need help?

Type /help how to ... in the comments thread for any questions about Qodo Merge usage.

Check out the documentation for more information.

[CLAassistant]

All committers have signed the CLA.

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Global Scope The change applies the function in the global window scope which could potentially affect other global variables or cause naming conflicts. Consider adding isolation mechanisms. "return (function(){%output%; return this." + EXPORT_FUNCTION_NAME + ".apply(null,arguments);}).apply(window, arguments);}"

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Security	Limit exposed window object scope The wrapper function applies the entire window object which could expose sensitive global variables. Consider limiting the scope to only required window properties. javascript/private/fragment.bzl [64] -"return (function(){%output%; return this." + EXPORT_FUNCTION_NAME + ".apply(null,arguments);}).apply(window, arguments);}" +"return (function(){%output%; return this." + EXPORT_FUNCTION_NAME + ".apply(null,arguments);}).apply({navigator: window.navigator, document: window.document}, arguments);}" Apply this suggestion Suggestion importance[1-10]: 8 __ Why: This is a significant security improvement as it limits the exposure of global window properties to only those necessary (navigator and document), reducing potential security vulnerabilities from exposing the entire window object.	Medium
General	Use more specific exported function name Consider using a more descriptive and collision-resistant name for the exported function. The current name could potentially clash with other libraries using similar naming patterns. javascript/private/fragment.bzl [3] -EXPORT_FUNCTION_NAME = '___exportedFunc___' +EXPORT_FUNCTION_NAME = '__selenium_exported_fragment_func__' Apply this suggestion Suggestion importance[1-10]: 6 __ Why: The suggestion improves code maintainability by using a more specific and less collision-prone name for the exported function, though the current name already includes underscores for namespacing.	Low
Learned best practice	Add validation with descriptive error messages when using global constants that must follow specific naming rules The new code introduces a global constant EXPORT_FUNCTION_NAME that is used in multiple places, but there's no validation to ensure the function name is valid. Add validation with descriptive error messages to verify the export function name follows JavaScript identifier naming rules. javascript/private/fragment.bzl [3-11] +def _validate_export_name(name): + if not name.isidentifier(): + fail(f"Invalid export function name: '{name}'. Must be a valid JavaScript identifier.") + EXPORT_FUNCTION_NAME = '___exportedFunc___' +_validate_export_name(EXPORT_FUNCTION_NAME) def _internal_closure_fragment_export_impl(ctx): ctx.actions.write( output = ctx.outputs.out, content = """ goog.require('%s'); goog.exportSymbol('%s', %s); """ % (ctx.attr.module, EXPORT_FUNCTION_NAME, ctx.attr.function), ) Apply this suggestion	Low

[ahalbrock]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category **Suggestion                                                                                                                                    ** Impact
Security
Limit exposed window object scope
The wrapper function applies the entire window object which could expose sensitive global variables. Consider limiting the scope to only required window properties.

javascript/private/fragment.bzl [64]

-"return (function(){%output%; return this." + EXPORT_FUNCTION_NAME + ".apply(null,arguments);}).apply(window, arguments);}"
+"return (function(){%output%; return this." + EXPORT_FUNCTION_NAME + ".apply(null,arguments);}).apply({navigator: window.navigator, document: window.document}, arguments);}"

• Apply this suggestion

Suggestion importance[1-10]: 8
Medium
General
Use more specific exported function name
Low
Learned
best practice
Add validation with descriptive error messages when using global constants that must follow specific naming rules
Low

These suggestions could certainly be taken into account although they don't seem necessary or aid in further maintenance of the code.

I am passing in window here as there have been issues brought forth where not everything was provided by the limited scope object passed in, using window would ensure everything is there.

I am certainly not against using an even more specific name for the function, I figured mine was odd yet descriptive enough to not produce collisions, but this can be more specific certainly if necessary.

I have only added the Skylark variable as the exported function name is used in two locations and I wanted to ensure it was easiest to deal with for future updates, previously there was no variable or validation of the exported function name (previously "_"). As there was no validation or explanation of the original, I'm uncertain it is necessary here (resulting JS errors should be sufficient).