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

Playwright: Automate Chromium, WebKit and Firefox

github.com

Post reply on HN
Print view View original

121–130 of 149 posts

Re: Playwright: Automate Chromium, WebKit and Firefox

#121

Post by zinekeller »

wizzwizz4 wrote: post #92
zamadatix wrote: post #64

Earlier quoted context omitted.

Microsoft's web products run on more than Edge.

They try very hard to stop you trying, though; Microsoft Teams has removed the “continue without the Teams app” button entirely on Firefox, even though I'm fairly sure it still works fine in Firefox.

I'm assuming you're not on macOS, right? Even though Firefox supports H.264, it's not really consistent outside of macOS because Firefox doesn't want to deal with patent hassles. This is true of Slack as well, some developers would actually support if Firefox has actually have decent support, but it's inconsistent outside macOS, where it can rely on Apple's good integration.

P.S. OpeH264 doesn't help mainly because it's decoding bugs, not encoding bugs.

Re: Playwright: Automate Chromium, WebKit and Firefox

#122

Post by 1vuio0pswjnm7 »

headlessvictim2 wrote: post #108
1vuio0pswjnm7 wrote: post #90

Earlier quoted context omitted.

Tell freemium users what is the acceptable rate for requests per second. Publish the allowable rate on the website. Ban freemium user IPs that exceed the allowable rate. This can be done using a proxy.

A proxy like Cloudflare or a custom proxy that stores data? Are there proxy examples you could point us to? Thanks for your help.

https://www.haproxy.com/blog/four-examples-of-haproxy-rate-l...

Re: Playwright: Automate Chromium, WebKit and Firefox

#123

Post by masklinn »

gmokki wrote: post #52
naasking wrote: post #14

Earlier quoted context omitted.

> If the execution in .NET is slow then I suppose it could be .NET. But it could be (and often is) the suite design. You must wait for /everything/ before interacting with it That's what I do, but the wait for an element in certain tests times out after a few minutes, even though the elements are clearly visible, and manual use never has an issue. From other comments it sounds like Puppeteer and Playwright are better…

When I fixed many similar selenium/webdriver tests the root cause was always the same: You grab reference to an element and for example wait it to become enabled or some text to appear. But your ui framework actually replaces the element in the dom while doing its thing and your reference to stale element will never change. Fix is to loop searching the element with selector and check if the element fills the conditio…

In my experience an other common issue is a race condition in the trigger, aka the system is not quite settled yet when an interaction is performed leading to that not registering.

This is more likely when the system is loaded / shared e.g. a CI Vm.

It’s instructive to watch a screencast / recording of UI tests, because you don’t necessary intuit how spazzy and fast the harness will perform its interactions.

Re: Playwright: Automate Chromium, WebKit and Firefox

#124

Post by nopenopenopeno »

abraham wrote: post #67
fikama wrote: post #55

Earlier quoted context omitted.

From what I know puppeter works only with chromium, this could be deal breaker for microsoft

Puppeteer has experimental Firefox support. https://pptr.dev/#faq:~:text=What%20is%20the%20status%20of%2...

I think that has been the case for a very long time.

Re: Playwright: Automate Chromium, WebKit and Firefox

#125

Post by nopenopenopeno »

axlee wrote: post #79
tnolet wrote: post #18

Earlier quoted context omitted.

We see a strong adoption of Playwright. It’s the default we recommend to users now. We also support Puppeteer, but its development is lagging. Having said that, I would love to support Cypress if I had infinite time and focus. Side note: Selenium is not on the menu, even with its large install base. We are aiming for where the puck is going and it’s going to Playwright. Full disclaimer: I’m CTO at Checkly.

How about Python bindings? Selenium is the only decent option in that space so far, are we wrong?

Playwright Python is excellent

Re: Playwright: Automate Chromium, WebKit and Firefox

#126

Post by hashseed »

throwthrow564 wrote: post #83
vlunkr wrote: post #53

Earlier quoted context omitted.

I wonder what the story is there. Why wouldn't MS just have him continue to work on Puppeteer? They're both open source, so there's not much point in "owning" their own clone of it.

I work at Google, but this is based on stuff I knew before I worked at Google, which I heard from a coworker. I haven't checked on the project since joining. The Puppeteer TL (the guy linked in the grandparent comment) apparently had ambitions to make Puppeteer work cross browser like Playwright does now. However, the Puppeteer project was heavily deprioritized and the TL would basically never be able to achieve thei…

I manage the team at Google that currently owns the Puppeteer project.

The previous team that developed Puppeteer indeed moved to Microsoft and have since started Playwright.

While it is true that staffing is tight (isn't it always), the number of open issues does not tell the full story. The team has been busy with addressing technical debt that we inherited (testing, architecture, migrating to Typescript, etc) as well as investing in a standardized foundation to allow Puppeteer to work cross-browser in the future. This differs from the Playwright team's approach of shipping patched browser binaries.

Re: Playwright: Automate Chromium, WebKit and Firefox

#128

Post by pawelbylina »

syspec wrote: post #39

Interesting tidbit: One of the main contributors of this project[0], was the core contributor (creator?) of Puppeteer[1], but then I guess left Google to join Microsoft and work on this[2][3]. [0] - https://github.com/aslushnikov [1] - https://github.com/puppeteer/puppeteer/ [2] - https://github.com/microsoft/playwright/graphs/contributors [3] - https://github.com/microsoft/playwright/graphs/contributors

[dead]

Re: Playwright: Automate Chromium, WebKit and Firefox

#129

Post by capableweb »

hashseed wrote: post #126
throwthrow564 wrote: post #83

Earlier quoted context omitted.

I work at Google, but this is based on stuff I knew before I worked at Google, which I heard from a coworker. I haven't checked on the project since joining. The Puppeteer TL (the guy linked in the grandparent comment) apparently had ambitions to make Puppeteer work cross browser like Playwright does now. However, the Puppeteer project was heavily deprioritized and the TL would basically never be able to achieve thei…

I manage the team at Google that currently owns the Puppeteer project. The previous team that developed Puppeteer indeed moved to Microsoft and have since started Playwright. While it is true that staffing is tight (isn't it always), the number of open issues does not tell the full story. The team has been busy with addressing technical debt that we inherited (testing, architecture, migrating to Typescript, etc) as w…

> The team has been busy with addressing technical debt that we inherited [...] migrating to Typescript

Wow, not writing stuff in TypeScript is now considered technical debt? I knew people were already rushing to rewrite everything in TypeScript if they could, but didn't knew we'd come this far along the hype-cycle already.

Re: Playwright: Automate Chromium, WebKit and Firefox

#130

Post by wizzwizz4 »

zinekeller wrote: post #121
wizzwizz4 wrote: post #92

Earlier quoted context omitted.

They try very hard to stop you trying, though; Microsoft Teams has removed the “continue without the Teams app” button entirely on Firefox, even though I'm fairly sure it still works fine in Firefox.

I'm assuming you're not on macOS, right? Even though Firefox supports H.264, it's not really consistent outside of macOS because Firefox doesn't want to deal with patent hassles. This is true of Slack as well, some developers would actually support if Firefox has actually have decent support, but it's inconsistent outside macOS, where it can rely on Apple's good integration. P.S. OpeH264 doesn't help mainly because i…

> Even though Firefox supports H.264, it's not really consistent outside of macOS because Firefox doesn't want to deal with patent hassles.

That's only a concern for video chats. Teams does a lot of other stuff too, and there's no reason you shouldn't be able to use that on Firefox.

Post reply on HN