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

Prototype: Puppeteer for Firefox

github.com

Post reply on HN
Print view View original

101–110 of 133 posts

Re: Prototype: Puppeteer for Firefox

#101

Post by Congeec »

zelo wrote: post #64
Congeec wrote: post #57

Earlier quoted context omitted.

Sorry I didn't defined the problems clearly and thank your for your help. I am using selenium using python for web automation, not testing. The latter problem was by and large solved by subclassing WebDriverWait by adding common Exceptions related to nodes staleness. The former problem was tackled by writing a for loop detecting changes of the context to know if WebElement.click() fails silently. The thing is I have…

Selenium for sure doesn't fit in your use case then :). I pointed "user-centric approach" because selenium focuses on allowing only things normal user could do in normal user way which is limiting for automation but it's a blessing if you want to look as close to the real user as you can. I worked on solving google ReCaptcha v2/v3 at bigger scale and it's been a solid advantage. > And javascript code in a string of p…

Thank you. The Language Injections feature amazes a vim user, though similar limited plugin exists.

Re: Prototype: Puppeteer for Firefox

#102

Post by kaycebasques »

mintplant wrote: post #90

Huh. I worked on exactly this idea as a Mozilla intern in 2017. I wrote a collection of Rust crates (mentioned in [0]) comprising auto-generated types for all Chrome DevTools Protocol messages [1], (de)serialization, and a server lib to handle both the initial HTTP handshake and subsequent command execution over WebSockets. I used that to build out an initial CDP server inside Firefox (and Servo) with support for a c…

There’s a lot of debate between the browser vendors and automation tools around whether the Chrome DevTools Protocol is the right abstraction layer to focus browser automation around. It’s a nuanced topic and if you dig into it you’ll see that all the different sides make good arguments. My guess is that this debate stalled your project. I’m putting myself out here on the topic because having a coherent and enjoyable cross-browser integration testing story would be a huge win for the web at large and it’s something worth making people aware of in the hopes that we can find common ground.

Edit: I actually have no right to comment on what stalled your project and have no idea what happened there. I just wanted to discuss the fact that we need a good abstraction layer but seem stuck in debate.

Disclosure: Chrome DevTools docs guy, just speaking personally based on my research into the topic over the last year

Re: Prototype: Puppeteer for Firefox

#104

Post by daveFNbuck »

Bjartr wrote: post #58
daveFNbuck wrote: post #33

Earlier quoted context omitted.

> Firefox offers nothing to developers over chrome, which is sad. Firefox has multi-account containers. Having different tabs logged in to different accounts is huge for me.

I use Chrome profiles to great effect.

Can't you only have one profile open at a time, and each one is linked to a different Google account?

Firefox allows you to have each tab open in a different container, and they don't have to be tied to anything in particular.

I can have different tabs open to the AWS console for each AWS account I use. I can also switch tabs to change between different user accounts to test interactions between users on the site I'm developing.

Re: Prototype: Puppeteer for Firefox

#105

Post by mintplant »

kaycebasques wrote: post #102
mintplant wrote: post #90

Huh. I worked on exactly this idea as a Mozilla intern in 2017. I wrote a collection of Rust crates (mentioned in [0]) comprising auto-generated types for all Chrome DevTools Protocol messages [1], (de)serialization, and a server lib to handle both the initial HTTP handshake and subsequent command execution over WebSockets. I used that to build out an initial CDP server inside Firefox (and Servo) with support for a c…

There’s a lot of debate between the browser vendors and automation tools around whether the Chrome DevTools Protocol is the right abstraction layer to focus browser automation around. It’s a nuanced topic and if you dig into it you’ll see that all the different sides make good arguments. My guess is that this debate stalled your project. I’m putting myself out here on the topic because having a coherent and enjoyable…

No need to apologize, I appreciate your perspective. That was my assumption as well at the time - that the debate had shifted the other way and CDP support fell off of the priority list.

Re: Prototype: Puppeteer for Firefox

#106

Post by mintplant »

itwy wrote: post #94
mintplant wrote: post #90

Huh. I worked on exactly this idea as a Mozilla intern in 2017. I wrote a collection of Rust crates (mentioned in [0]) comprising auto-generated types for all Chrome DevTools Protocol messages [1], (de)serialization, and a server lib to handle both the initial HTTP handshake and subsequent command execution over WebSockets. I used that to build out an initial CDP server inside Firefox (and Servo) with support for a c…

Are you saying they didn't credit you for your work?

I'm not saying that. Just sharing my experience and expressing surprise at the reappearance of what I thought was a dead project.

Re: Prototype: Puppeteer for Firefox

#107

Post by jamesgeck0 »

mceachen wrote: post #92
ppf wrote: post #62

Earlier quoted context omitted.

How would you describe the npm install process?

Just like any other module, but slower. There's a substantial bag of bits it needs to fetch (chromium), but that's cached. I've also noticed that sometimes (in CI, less than 5% of the runs) the installation or run will fail deep in chromium. It's actually spawning a chrome process and tunneling remote commands to the child process to do work, so, I guess the flakiness is (almost) excusable? Restarting the test always…

You can install Puppeteer without downloading the bundled Chromium (PUPPETEER_SKIP_CHROMIUM_DOWNLOAD env variable), but you need to be careful to use it with a version of Chrome/Chromium that has a compatible dev tools api version.

I too have experienced flakiness in CI where Chrome doesn't always seem to start or quit within a reasonable amount of time. I get around this in production with timeouts that give any lingering Chrome processes a series of increasingly aggressive requests to quit, but my hosted CI environment doesn't like it when I send kill signals to random PIDs.

I'm hoping that this Firefox client will be somewhat more reliable in that regard.

Re: Prototype: Puppeteer for Firefox

#108

Post by jamesgeck0 »

mikepurvis wrote: post #65
nostalgk wrote: post #63

Earlier quoted context omitted.

I have never heard of TestCafe, but I've used Puppeteer for a variety of projects with Chrome. My latest one was using it to convert HTML files into PDFs en masse.

Is there an advantage to that approach over the more direct wkhtmltopdf?

My experience with wkhtmltopdf a few years ago was that the PDFs that it rendered could look quite different from the PDFs that Chrome or Firefox would render.

Re: Prototype: Puppeteer for Firefox

#109

Post by jamesgeck0 »

daveFNbuck wrote: post #104
Bjartr wrote: post #58

Earlier quoted context omitted.

I use Chrome profiles to great effect.

Can't you only have one profile open at a time, and each one is linked to a different Google account? Firefox allows you to have each tab open in a different container, and they don't have to be tied to anything in particular. I can have different tabs open to the AWS console for each AWS account I use. I can also switch tabs to change between different user accounts to test interactions between users on the site I'm…

> Can't you only have one profile open at a time

No. Each profile opens in a new Chrome window. You can have as many open as you'd like.

> and each one is linked to a different Google account?

No. Local profiles have always been a thing.

Chrome's implementation has better UX for privacy IMHO; it's harder to accidentally open a tab in a different profile than expected, which I do _all the time_ in Firefox. In Chrome, Cmd+T opens a new tab in the active profile. In Firefox, Cmd+T opens a new tab in the default profile.

Post reply on HN