Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Puppeteer Support for Firefox

hacks.mozilla.org

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Puppeteer Support for Firefox

#81

Post by _heimdall »

regularfry wrote: post #78
_heimdall wrote: post #56

Earlier quoted context omitted.

I have always wanted a browser automation tool that taps directly into the accessibility tree. Plenty do supporting querying based on accessibility features, but unless I'm mistaken none go directly to the same underlying accessibility tree used by screen readers and similar. Happy to be wrong here if anyone can correct me. The idea of all tests confirming both functionality and accessibility in one go would be much…

Guidepup looks like it's a decent stab in that direction: https://www.guidepup.dev/ Only Windows and MacOS though, which is a problem for build pipelines. I too would very much like the page descriptions and the accessibility inputs to be the primary way of driving a page. It would make accessible access the default, rather than something you have to argue for.

That's an interesting one, thanks!

Skimming through their getting started, I wonder how translations would be handled. It looks like the tests expect to validate what the actual screen reader says rather than just the tree, for example their first test shows finding the Guidepup header in their readme my waiting for the screen reader to say "Guidepup heading level 1".

If you need to test different languages, you'd have to match the phrasing used by each specific screen reader when reading the heading descriptor and text. All your tests are also actually vulnerable to any phrasing changes made to each screen reader. If VoiceOver changed something it could break all your test values.

I bet they could hide that behind abstractions though, `expectHeading("Guidepup", 1)` or similar. Ideally it really would just be a check in the tree though, avoiding any particular implementation of a screen reader all together.

Re: Puppeteer Support for Firefox

#82

Post by bdcravens »

e12e wrote: post #27

What are reasons to prefer puppeteer to playwright which supports many browsers? > Cross-browser. Playwright supports all modern rendering engines including Chromium, WebKit, and Firefox. https://playwright.dev/

Additionally, Playwright has some nice ergonomics in the API, though Puppeteer has since implemented a lot of it as well. Downloads and video capturing in Playwright is nicer.

Re: Puppeteer Support for Firefox

#83

Post by jesprenj »

Nextgrid wrote: post #62
jesprenj wrote: post #51

What I very dislike about current browser automation tools is that they all use TCP for connecting the browser with the manager program. This means that, unlike for UNIX domain sockets, filesystem permissions (user/group restrictions) cannot be used to protect the TCP socket, which opens the browser automation ecosystem to many attacks where 127.0.0.1 cannot be trusted (untrusted users on a shared host). I have yet t…

Spawn it in a dedicated network namespace (to contain the TCP socket and make it unreachable from any other namespace) and use `socat` to convert it to a UNIX socket.

This is not always possible as some machines don't support network namespaces, but it's a perfectly valid solution. But this solution is Linux-only, do BSD OSes like MacOS support UID and NET namespaces?

Re: Puppeteer Support for Firefox

#84

Post by bdcravens »

nsonha wrote: post #61
cebert wrote: post #35

Earlier quoted context omitted.

Playwright is such a good experience. I don’t understand why you would need something like browserbase.

have you actually done any web scrapping at scale? The problem is never the web automation. It's bypassing IP blacklist, rate limits, capcha etc, and a hosted service can provide solutions for those: > Proxies included..., Auto Captcha Solving, Advanced Stealth Mode Other than that, like everything else, a hosted service is always an option and not contradict with you being able to host that service directly, they're…

I have, and solved a lot of those problems. Yes, it requires additional plugins and services, but I prefer to own the solution (a must-have for my use case, but for someone where it's lower stakes perhaps a hosted solution is ideal to the engineering/research)

Re: Puppeteer Support for Firefox

#85

Post by twic »

nox101 wrote: post #67
hugs wrote: post #2

Ranked #4 on HN at the moment and no comments. So I'll just say hi. (Selenium project creator here. I had nothing to do with this announcement, but feel free to ask me anything!) My hot take on things: When the Puppeteer team left Google to join Microsoft and continue the project as Playwright, that left Google high and dry. I don't think Google truly realized how complementary a browser automation tool is to an AI-a…

Last time I tried playwright it required custom versions of the browsers. That meant it was impossible to use with any newer browser features. That made it impossible to use if you wanted to target new and advanced use cases or prep a site in expectation of some new API feature that just shipped or is expected to ship soon. If you used playwright, write tons of tests, then hear about some new browser feature you want…

It works for me with stock Chromium and Chrome on Linux. But for Firefox, i apparently need a custom patched build, which isn't available for the distro i run, so i haven't confirmed that.

Re: Puppeteer Support for Firefox

#86

Post by jesprenj »

JoelEinbinder wrote: post #52
jesprenj wrote: post #51

What I very dislike about current browser automation tools is that they all use TCP for connecting the browser with the manager program. This means that, unlike for UNIX domain sockets, filesystem permissions (user/group restrictions) cannot be used to protect the TCP socket, which opens the browser automation ecosystem to many attacks where 127.0.0.1 cannot be trusted (untrusted users on a shared host). I have yet t…

You can set `pipe` to true in puppeteer (default false) here https://pptr.dev/api/puppeteer.launchoptions By default, Playwright launches this way and you have to specifically enable the tcp listening.

Great, I stand corrected! I still don't know how they convince firefox/chromium to use a pipe as a websocket transport layer.

Re: Puppeteer Support for Firefox

#88

Post by tracker1 »

nox101 wrote: post #67
hugs wrote: post #2

Ranked #4 on HN at the moment and no comments. So I'll just say hi. (Selenium project creator here. I had nothing to do with this announcement, but feel free to ask me anything!) My hot take on things: When the Puppeteer team left Google to join Microsoft and continue the project as Playwright, that left Google high and dry. I don't think Google truly realized how complementary a browser automation tool is to an AI-a…

Last time I tried playwright it required custom versions of the browsers. That meant it was impossible to use with any newer browser features. That made it impossible to use if you wanted to target new and advanced use cases or prep a site in expectation of some new API feature that just shipped or is expected to ship soon. If you used playwright, write tons of tests, then hear about some new browser feature you want…

IIRC, you can use the system installed browser, but need to know the executable path when launching. I remember it being a bit of a pain to do, but have done it.

Re: Puppeteer Support for Firefox

#89

Post by localfirst »

hugs wrote: post #58
localfirst wrote: post #53

Earlier quoted context omitted.

> Could probably write a book about the lessons learned getting a "vision first" approach to automation working ha that would be splendid! please do maybe even a blog on valetnet.dev (lovely site btw a demo or video would be a nice) I'm convinced vision first is the way to go despite people saying its slow the benefits are tremendous as lot of websites simply do not play nice with HTML and I do not like having to ins…

Agreed on the need for a demo. #1 on the TODO list! If I know at least one person will read it, I might even do a blog, too! :) The rise of multi-modal LLMs is making "vision first" plausible. However, my basic test is asking these models to find the X,Y screen coordinates of the number "1" on a screenshot of a calculator app. ChatGPT-4o still can't do it. Same with LLaVA 1.5 last I tried. But I'm sure it'll get ther…

You already have a fan! Feel free to contact me if you need more traffic i'll be sure to spread the word.

Re: Puppeteer Support for Firefox

#90

Post by dataviz1000 »

creesch wrote: post #75
dataviz1000 wrote: post #74

Earlier quoted context omitted.

I'm not convinced. It looks like v0.10.0 contains ~half of Google's Puppeteer code and even in the latest release[0]the core package references Google's copyright several hundred times. Conceptually, the core, the bridge between a node server and the injected Chrome DevTools Protocol scripts are the same. Looks like Playwright started as a fork and evolved as a wrapper that eventually included APIs for Python and Jav…

As I said, even if playwright started out a fork, classifying it as just that these days is a pretty big oversimplification. It isn't just a "wrapper around puppeteer" either but a complete test automation framework bringing you the whole set of runner, assertion library and a bunch of supporting tools in the surrounding ecosystem. Where puppeteer still mainly is a library and just that. With which there in principle…

> at this stage of development does make them distinctly different products

I agree with that.

The base concept is the same, there is a map between element handles on the server and elements in the browser contexts which are synced over channels with websockets. The user creates an element handle in the sever and the element gets wrapped inside the browser context with a unique id. Any events emitted by the element, are sent over websockets to the server.

At one point, I had used this code to inject a script into browser contexts with a Chrome Extension which communicated with a server over websockets to automate browsers with the Chrome Extension installed.

Post reply on HN