Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(prefs): add ability to launch browser with desired preferences #1806

Closed
wants to merge 1 commit into from

Conversation

skyiea
Copy link

@skyiea skyiea commented Jan 15, 2018

The ability to start browser with desired preferences.
Related issue

The easier way to kickoff was to allow to set prefs for the cases when there is no preconfigured userDataDir / --user-data-dir and to see the feedback from the maintainers.
What's done:

  • implementation
  • write tests
  • update documentation

What could be done as a separate feature:

  • allow setting prefs in conjunction with userDataDir / --user-data-dir
  • add ability to set "local state" prefs

@aslushnikov WDYT?

@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.


  • If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.
  • If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot. The email used to register you as an authorized contributor must be the email used for the Git commit.
  • In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

@skyiea skyiea closed this Jan 15, 2018
@skyiea skyiea reopened this Jan 15, 2018
@googlebot
Copy link

CLAs look good, thanks!

@skyiea
Copy link
Author

skyiea commented Jan 16, 2018

I signed it!

@aslushnikov
Copy link
Contributor

@skyiea This looks good! Looking forward to landing this.

@skyiea
Copy link
Author

skyiea commented Jan 20, 2018

@aslushnikov Added tests and updated docs.

@skyiea skyiea changed the title feat(prefs): added ability to launch browser with desired preferences feat(prefs): add ability to launch browser with desired preferences Jan 20, 2018
@@ -76,6 +78,13 @@ class Launcher {

chromeArguments.push(`--user-data-dir=${options.userDataDir || temporaryUserDataDir}`);
}
if (options.prefs) {
console.assert(!options.headless, `Custom preferences can't be used in headless mode`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a bummer. I didn't know preferences are not supported by headless browser. We try hard not to land API that works only in headful browser.

@skyiea can you please share what particular preferences are you interested in? We might be able to plumb them for you through DevTools protocol so that it works in both headful and headless modes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was surprised too that it doesn't work in headless browser, given that headless supports custom userDataDir and, say, localStorage/cookies. Might be some of you guys have some insight why Preferences file is being ignored in headless?
Personally for me it makes no difference, because I'm using puppeteer to test Chrome extension, which means that I don't have a chance to use headless mode anyway (BTW, any insight why so?). Thus I guess many of the users are already using puppeteer in headful mode.

That's not only about my particular case, I guess. As I've said, there is a lot (https://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/pref_names.cc?view=markup) of additional settings that are available via preferences. For me it allows to set prefs.download.default_directory (setDownloadBehavior doesn't work for me, I guess because I'm downloading via chrome.downloads API), and in the future I'd like to be able to trigger some experiments (via prefs.experiments_enabled).

@skyiea
Copy link
Author

skyiea commented Feb 1, 2018

@aslushnikov Any updates on this?

@aslushnikov
Copy link
Contributor

@skyiea I apologize for the long delay.

@aslushnikov Any updates on this?

It turns out preferences are part of chrome/ layer in Chromium, not content/; I wasn't aware of this.

Landing this PR will introduce more inconsistency in headless vs headful modes, which I very much want to avoid. I think you can implement this functionality as a utility method for your needs, or even publish as NPM module. Will this work for you?

I'm sorry for misleading you on this feature.

@aslushnikov
Copy link
Contributor

Closing this as per previous comment.

@berstend
Copy link

In case anyone else who needs this ends up here, I've published a small wrapper to enable custom preferences in puppeteer: https://github.com/berstend/puppeteer-extra

Heavily inspired by @skyiea's PR, thanks! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants