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

61–70 of 92 posts

Re: Puppeteer Support for Firefox

#61

Post by nsonha »

cebert wrote: post #35
whatnotests2 wrote: post #25

For an alternative approach, try browserbase.com * https://browserbase.com/

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 just for different sets of constrains.

Re: Puppeteer Support for Firefox

#62

Post by Nextgrid »

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.

Re: Puppeteer Support for Firefox

#64

Post by _heimdall »

jahewson wrote: post #59
_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…

It depends on what you’re testing. Much of a typical page is visual noise that is invisible to the accessibility tree but is often still something you’ll want tests for. It’s also not uncommon for accessible ui paths to differ from regular ones via invisible screen-reader only content, eg in a complex dropdown list. So you can end up with a situation where you test that accessible path works but not regular clicks! I…

Yeah those are interesting corner cases for sure.

When UI is only visual noise and has no impact on functionality, I don't see much value in automated testing for it. In my experience these cases are often related to animations and notoriously difficult to automate tests for anyway.

When UX diverges between UI and the accessibility tree, I'd really expect that to be the exception rather than the rule. There would need to be a way to test both in isolation, but when one use case diverges down two separate code paths it's begging for hard to find bugs and regressions.

Totally agree on testing with screen readers directly though. I can't count how many weird differences I've come across between Windows (IE or Edge) and Mac over the years. If I remember right, there was a proposed spec for unifying the accessibility tree and related APIs but I don't think it went anywhere yet.

Re: Puppeteer Support for Firefox

#65

Post by creesch »

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/

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.

Re: Puppeteer Support for Firefox

#66

Post by creesch »

imiric wrote: post #26
huy-nguyen wrote: post #21

Earlier quoted context omitted.

What’s the relationship between Selenium, Puppeteer and Webdriver BiDi? I’m a happy user of Playwright. Is there any reason why I should consider Selenium or Puppeteer?

> Is there any reason why I should consider Selenium or Puppeteer? I'm not a heavy user of these tools, but I've dabbled in this space. I think Playwright is far ahead as far as features and robustness go compared to alternatives. Firefox has been supported for a long time, as well as other features mentioned in this announcement like network interception and preload scripts. CDP in general is much more mature than W…

Both Selenium and Playwright are very solid tools, a lot simply comes down to choice and experience.

One of the benefits of using Selenium is the extensive ecosystem surrounding it. Things like Selenium grid make parallel and cross-browser testing much easier either on self hosted hardware or through services like saucelabs. Playwright can be used with similar services like browserstack but AFAIK that requires an extra layer of their in-house SDK to actually make it work.

Selenium also supports more browsers, although you can wonder how much use that is given the Chrome dominance these days.

Another important difference is that Playwright really is a test automation framework, where Selenium is "just" a browser automation library. With Selenium you need to bring the assertion library, testrunner, reporting in yourself.

Re: Puppeteer Support for Firefox

#67

Post by nox101 »

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 to target to get ahead of your competition, you'd have to refactor all of your tests away from playwright to something that could target chrome canary or firefox nightly or safari technology preview.

Has that changed?

Re: Puppeteer Support for Firefox

#68

Post by irjustin »

creesch wrote: post #65
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/

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.

I also wonder the same. Playwright is so good. I simply don't have flaky tests even when dealing with features that are playwrights' fault.

I used to have so many issues with Selenium and so only used it in must have situations defaulting to capybara to run out specs.

Re: Puppeteer Support for Firefox

#69

Post by dataviz1000 »

creesch wrote: post #65
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/

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.

Re: Puppeteer Support for Firefox

#70

Post by joshuaissac »

djbusby wrote: post #32
yoavm wrote: post #30

I know this isn't what the WebDriver BiDi protocol is for, but I feel like it's 90% there to being a protocol through which you can create browsers, with swappable engines. Gecko has gone a long way since Servo, and it's actually quite performant these days. The sad thing is that it's so much easier to create a Chromium-based browser than it is to create a Gecko based one. But with APIs for navigating, intercepting r…

I have dreamed about a swappable engine. Like, a wrapper that does my history and tabs and book marks - but let's me move from rendering in Chrome or Gecko or Servo or whatever.

There are some browsers that support multiple rendering engines out of the box, like Maxthon (Blink + Trident) and Lunascape (Blink + Gecko + Trident).
Post reply on HN