Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Suggestion] Unify launch() and launchPersistentContext() options

See original GitHub issue

Right now the launch() and launchPersistentContext() calls support different options. The latter one supports the following options that are missing from the first one:

acceptDownloads
ignoreHTTPSErrors
deviceScaleFactor
isMobile
hasTouch
javaScriptEnabled
timezoneId
geolocation
locale
permissions
extraHTTPHeaders
offline
httpCredentials
colorScheme

Is there any specific reason that these two do not share the same options? Especially some options like userAgent would be quite useful to support in the regular launch() call.

Issue Analytics

State:
Created 3 years ago
Comments:7 (4 by maintainers)

Top GitHub Comments

1reaction

yury-scommented, Jul 2, 2020

I can’t think of a reason to launch a browser without the need for a context.

That’s a fair point, there is little reason to launch browser if you are not going to create a page in it 😄 The rationale for the Browser/Context/Page API is that BrowserContext is what we consider the primary isolation mechanism between different test cases. In the common case we expect Playwright to be used in a test suite where the tests could share same browser instance (for performance reasons) while create separate browser contexts and have their own network, geolocation, locale, timezone etc parameters isolated between the test cases (each would use its own context).

Since the docs suggest the launch().newPage() method, that would be a more logical flow IMHO. Just my 2 cents

Yeah, Browser.newPage was added to make life easier for the people with muscle memory from Puppeteer and so that newcomers could start prototyping sooner without having to learn extra concept of BrowserContext.

0reactions

Niekcommented, Jul 2, 2020

OK, I understand the reasoning.

But if you ask me, a more logical API design would have been to add all options to launch() and return a BrowserContext right away, I can’t think of a reason to launch a browser without the need for a context. If it would be structured like this you wouldn’t need a Browser.newPage() method which is confusing anyway. Since the docs suggest the launch().newPage() method, that would be a more logical flow IMHO. Just my 2 cents 😄

Top Results From Across the Web

[BUG] when use chromium.launchPersistentContext, video ...

I have to launch Chrome in non incognito mode and thus I have to create browser using launchPersistentContext(). Thus if I use this...

Playwright v1.1.0 release notes (2020-06-09) | LibHunt

First-class proxy support using proxy option in browserType.launch() ... launchPersistentContext() now supports a wide variety of browser context options.

BrowserType (Playwright - Main Library 1.22.0 API) - javadoc.io

BrowserType provides methods to launch a specific browser instance or connect to an ... The default browser context is accessible via Browser.contexts() ....

codeceptjs | Yarn - Package Manager

Assertions start with see or dontSee prefix. ... [Playwright] Implemented launchPersistentContext to be able to launch ... Introduced lodash.merge() .

BrowserType | Playwright 中文文档

BrowserType · browserType.connect(params)# · browserType.executablePath()# · browserType.launch([options])# · browserType.launchPersistentContext(userDataDir[, ...