natorion

Playwright is shipping patched browsers. They take the open source version of the browser and patch in e.g. CDP support or other things that make automation "better. Playwright does not work with a "normal" Safari for example.

You would be surprised how much we talked about that . New/old are just relevant for the transition period.

It's real Chromium, not emulating a Chromium browser. "Old" Headless was merely pretending to be a Chromium browser, the "New" Headless is a Chromium browser. "Old" Headless requires a parallel/duplicate implementation of features, which leads to subtle behavior differences or infeasability to support certain features e.g. extensions proper.

Here are two of them: -Test reproducibility -Automated configuration rollouts in enterprise environments

We regularly get feature requests for Headless to provide a field or property that can be polled by JS frameworks to detect if Headless is active e.g. windows.isBot.

Well, Headless is open source, which means anybody could build a Headless version with such a property set to "I am a human, trust me!" and employ such a modified binary ... ;-)

I fail to see the connection. Can you elaborate?

What rumors? Can you provide any links or context?

PM working on Headless here. Masking bots is not the reason why the new Headless mode was created. The goal is to provide an headless browser that can be used in web tests. The original Headless is essentially a separate browser implemented in parallel to "proper" Chromium. That results in all sorts of subtle reproducibility problems for developers using Headless for their tests.

I am the PM working on Headless. Feel free to ask questions in this thread and I will try to answer them if I can.

Can you please file a bug report on crbug.com?

You might also know this as PERT (https://de.wikipedia.org/wiki/Program_evaluation_and_review_...)

I used it in the past and I think it is a good framework to discover uncertainty and make it more visible, because it makes you talk about optimistic and pessimistic cases.

The estimates are also good enough to come up with a draft schedule.

Google in Germany is hiring quite alright.

You can enable it on Firefox nightly. I think the config name is something with shared_mem.

Yes, atomics and SABs are tied to SI being active.

C++

Devs need to do feature detection like with any other feature e.g. for the presence of atomics and sharedarraybuffers.

Indeed. X64 and ia32 support vor Liftoff will be in 69.

It is progressing quite nicely. We still don't know yet when it is ready to graduate from Canary/Dev though. Lot's of stuff to do!

Great summary with a few nits!

I am not aware that Edge is "stupidly fast" on startup. Safari though, is indeed currently leading the field.

As you correctly outlined, V8 is indeed transitioning to a world with an interpreter+optimizing compiler only. If you are using Chrome Canary, there is a chance that you are already using the new pipeline :-).

Full disclosure: I work on the V8 team.

There are tools with more depths: You can try about:tracing or the heap visualizer mentioned in the article.

According to tests it doesn't. The heap memory optimization will only trigger on mobile devices <512MB ram. The zone memory improvements shouldn't have a negative effect.

It would be interesting to get feedback how much this helped Electron.

Keep in mind that this blog post is talking about V8 memory and not Chrome memory. The percentage for Chrome is obviously lower.

V8 recently introduced the flag --minimal which only uses Ignition. The intention behind the flag is to bootstrap porting though.

That sums it up quite well.

Try/catch/finally is handled by TurboFan (one of V8's optimizing compilers) - see https://groups.google.com/forum/#!topic/v8-users/maH60gh_a8s for more detail. There is a certain set of features which go through TurboFan instead of CrankShaft (the other optimizing compiler).

Disclaimer: I work on the V8 team.