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).
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.
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.
> 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.
