Skip to content

docs(proposal): Firefox-based stealth option for browser helper#5847

Draft
feder-cr wants to merge 1 commit into
jxxghp:v2from
feder-cr:proposal-invisible-firefox-helper
Draft

docs(proposal): Firefox-based stealth option for browser helper#5847
feder-cr wants to merge 1 commit into
jxxghp:v2from
feder-cr:proposal-invisible-firefox-helper

Conversation

@feder-cr
Copy link
Copy Markdown

opening as draft to check interest before building the helper resolver branch.

would an optional invisible_firefox value for PLAYWRIGHT_BROWSER_TYPE be in scope, parallel to the chromium and firefox values added in PR #5250? selected via config, no change to defaults.

motivation: CloakBrowser is already wired into app/helper/browser.py as the Chromium-stealth path. private trackers and some media-info sources work better with Firefox UA, and a few have started rate-limiting CloakBrowser's Chromium UA pattern.

the backend would wrap feder-cr/invisible_playwright, which drives a patched Firefox 150 (feder-cr/invisible_firefox, MPL-2, same license as Firefox upstream, fingerprint patches at the C++ source level). drop-in compatible with the existing BrowserContext / BrowserPage / BrowserElement protocols. optional dependency.

this PR only adds a proposal doc in docs/ so the idea has somewhere concrete to land. tracking discussion: #5846

if not in scope i'll close without noise.

Adds a draft proposal for an invisible_firefox value for
PLAYWRIGHT_BROWSER_TYPE, parallel to the chromium and firefox
options added in PR jxxghp#5250. Opened as draft to check interest
before building the helper resolver branch.
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request proposes a Firefox-based stealth option (invisible_firefox) for the browser helper to bypass rate limits and compatibility issues associated with Chromium. The review feedback points out that the proposal's maintenance section underestimates the required changes; simply updating the resolver in PlaywrightHelper.__init__ is insufficient because execution methods like action and get_page_source currently hardcode the use of cloakbrowser and must be refactored to dynamically select the browser context.


## Maintenance

Issues against the backend route to feder-cr/invisible_playwright. Only ask of this repo would be the resolver branch in `PlaywrightHelper.__init__` plus a config docstring update.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

medium

In app/helper/browser.py, PlaywrightHelper currently hardcodes the use of cloakbrowser (via self.__launch_cloakbrowser_context) in both action and get_page_source methods, completely ignoring self.browser_type.

Therefore, simply adding a resolver branch in PlaywrightHelper.__init__ will not be sufficient. The execution methods (action and get_page_source) will also need to be refactored to dynamically select and launch the appropriate browser context (e.g., standard Playwright, CloakBrowser, or invisible_playwright) based on self.browser_type or self.__browser_emulation().

Please update the proposal to reflect these required changes in the browser helper execution flow.

Suggested change
Issues against the backend route to feder-cr/invisible_playwright. Only ask of this repo would be the resolver branch in `PlaywrightHelper.__init__` plus a config docstring update.
Issues against the backend route to feder-cr/invisible_playwright. The implementation would require updating the resolver in PlaywrightHelper and refactoring its execution methods (action and get_page_source) to dynamically route to the correct browser context launcher based on self.browser_type, along with a config docstring update.

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.

1 participant