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

71–80 of 92 posts

Re: Puppeteer Support for Firefox

#71

Post by jgraham »

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…

There's an issue open for this on the WebDriver BiDi issue tracker.

We started with WebSockets because that supports more use cases (e.g. automating a remote device such as a mobile browser) and because building on the existing infrastructure makes specification easier.

It's also true that there are reasons to prefer other transports such as unix domain sockets when you have the browser and the client on the same machine. So my guess is that we're quite likely to add support for this to the specification (although of course there may be concerns I haven't considered that get raised during discussions).

Re: Puppeteer Support for Firefox

#72

Post by creesch »

dataviz1000 wrote: post #69
creesch wrote: post #65

Earlier quoted context omitted.

Good question, even more so considering they were made by the same people. After the creators of puppeteers moved to Microsoft and started work on Playwright, I got the impression that puppeteer was pretty much abandoned. Certainly in the automation circles I find myself in I barely see anyone using or talking puppeteer unless it is a bit of legacy project.

If you open up the code Playwright codebase you will discover that it is literally Puppeteer with the copyright message header in the base files belonging to Google. It is a fork.

That is a huge oversimplification, if I ever saw one. If you look at the early commits, you can see that it isn't just a simple fork. For starters, the initial commit[1] is already using Typescript. As far as I am aware puppeteer is not and is written in vanilla JavaScript.

The license notice you mention is indeed there [2], but also isn't surprising they wouldn't reinvent the wheel for those things they wrote earlier and that simply work. Even if they didn't directly use code, Microsoft would be silly to not add it given their previous involvement with puppeteer.

Even if it was originally a fork, they are such different products at this point that at best you could say that playwright started out as a fork (Which, again, it did not as far as I can tell).

[1] https://github.com/microsoft/playwright/commit/9ba375c063448...

[2] https://github.com/microsoft/playwright/blob/3d2b5e680147577...

Re: Puppeteer Support for Firefox

#74

Post by dataviz1000 »

creesch wrote: post #72
dataviz1000 wrote: post #69

Earlier quoted context omitted.

If you open up the code Playwright codebase you will discover that it is literally Puppeteer with the copyright message header in the base files belonging to Google. It is a fork.

That is a huge oversimplification, if I ever saw one. If you look at the early commits, you can see that it isn't just a simple fork. For starters, the initial commit[1] is already using Typescript. As far as I am aware puppeteer is not and is written in vanilla JavaScript. The license notice you mention is indeed there [2], but also isn't surprising they wouldn't reinvent the wheel for those things they wrote earlie…

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 Java around Puppeteer. At the core there is a ton of code still used from Puppeteer.

[0] https://github.com/microsoft/playwright/tree/48627ad48405583...

Re: Puppeteer Support for Firefox

#75

Post by creesch »

dataviz1000 wrote: post #74
creesch wrote: post #72

Earlier quoted context omitted.

That is a huge oversimplification, if I ever saw one. If you look at the early commits, you can see that it isn't just a simple fork. For starters, the initial commit[1] is already using Typescript. As far as I am aware puppeteer is not and is written in vanilla JavaScript. The license notice you mention is indeed there [2], but also isn't surprising they wouldn't reinvent the wheel for those things they wrote earlie…

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 is nothing wrong, but at this stage of development does make them distinctly different products.

Re: Puppeteer Support for Firefox

#76

Post by mst »

weaksauce wrote: post #19
localfirst wrote: post #7

Earlier quoted context omitted.

I see im still looking for a way to control browser from the inside via an extension browser. very tough problem to solve.

are you using native messaging? there's a way to bridge a program running with full permissions inside the computer that could use puppeteer or the like. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... seems like it wouldn't be that hard to sync the two but the devil is in the details. also installing the native script is outside the purview of the webext so you need to have an installer.

If it's a single file you could just make it a download.

There's also the newer file system APIs (though in Safari you'll be missing features and need to put some things in a Web Worker).

Re: Puppeteer Support for Firefox

#77

Post by devjab »

SomaticPirate wrote: post #5
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…

If I wanted to write some simple web-automation as a DevOps engineer with little javascript (or webdev experience at all) what tool would you recommend? Some example use cases would be writing some basic tests to validate a UI or automate some form-filling on a javascript based website with no API.

I’d go with puppeteer for your use case as it’s the easier option to set up browser automation with. But it’s not like you can really go wrong with playwright or selenium either.

Playwright only really gets better than puppeteer if you’re doing actual website testing of a website you’re building which is where it shines.

Selenium is awesome, and probably has more guide/info available but it’s also harder to get into.

Re: Puppeteer Support for Firefox

#78

Post by regularfry »

_heimdall wrote: post #56
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…

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.

Re: Puppeteer Support for Firefox

#79

Post by jgraham »

ed_mercer wrote: post #73

Shouldn’t the title be “Firefox support for puppeteer”?

Well the truth is it's both.

We had to change Firefox so it could be automated with WebDriver BiDi. The Puppeteer team had to change Puppeteer in order to implement a WebDriver BiDi backend, and to enable specific support for downloading and launching Firefox.

As the article says, it was very much a collaborative effort.

But the announcement is specifically about the new release of Puppeteer, which is the first to feature non-experimental support for Firefox. So that's why the title's that way around.

Re: Puppeteer Support for Firefox

#80

Post by notpublic »

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…

run it inside podman/docker
Post reply on HN