v2.0 Breaking Changes

[aslushnikov]

These are the breaking changes we'd like to have for v2.0:

• set initial viewport size to 1280 x 1024 - Behavior of setViewport() inconsistent in Headful #1910 (not doing this for 2.0 - doesn't seem worth the hassle)
• make browser.disconnect async: sockets don't close instantly.
• make page.evaluate to throw for the non-serializable values (e.g. objects with circular references) Evaluate silently masking errors #2864
• refactor response.securityDetails() into response.certificate() and actually include certificate data (DEPRECATE OLD ONE)
• consider switching to pipes instead of websocket connection by default (not doing this - not worth the hassle)
• consider dropping node6 support (chore: drop Node.js v6 support #5045)
• consider renaming waitForSelector's "visible" option into "interactable" since we also have a real visibility with IntersectionObserver. feat(elementhandle): introduce elementHandle.isIntersectingViewport() method. #2673
• consider passing calling frame as the first argument to the function exposed via page.exposeFunction. Is there a way to get the Frame that's calling function set by exposeFunction? #2126 (BETTER DO A frame.exposeFunction to expose per-frame)
• use single "defaultTimeout" option to setup default timeout for all methods. The option should support 0 to help with debugging. Feature request: add an option to control all default timeouts in one place #3158
• move to flatten protocol. refactor: move to flatten protocol #3524
• move page.tracing to browser.tracing; pass a page to capture screenshots of as a method argument. How to use page.tracing.start ?? - UnhandledPromiseRejectionWarning: Error: Protocol error (Tracing.start): Tracing is already started #3639 (DEPRECATE THE OLD API)
• make page.screenshot clip elements to the viewport per upstream Chromium changes. This matches the clipping behavior of elements in inner scrollers, i.e. document and overflow scroll clipping now work the same.
• rename page.emulateMedia to page.emulateMediaType (DEPRECATE THE OLD API). This is technically not a breaking chance since we'll keep an alias for now. feat(api): add page.emulateMedia{Type,Features} #5012

[yanivefraim]

Can I please take:

make page.evaluate return puppeteer.UNSERIALIZABLE_VALUE for the non-serializable values (e.g. objects with circular references)

and

set initial viewport size to 1280 x 1024

?

[aslushnikov]

Can I please take:

@yanivefraim we're not quite ready yet for the 2.0; we'll wait for more things to pile up and then start implementing the breaking changes.

[JoelEinbinder]

I think we should switch to pipes by default over websocket in 2.0

[benjamingr]

I really think faster serialisation of non-trivial values would make puppeteer more appealing to more users. That is, passing data quickly between puppeteer and Node.js would enable people to use puppeteer for whole new things.

[transitive-bullshit]

Where can I find more info on the Puppeteer's timeline for this and general product roadmap?

Thanks!!

[paambaati]

@JoelEinbinder @aslushnikov Is there a reason why pipe mode will be the new default? I'd asked a similar question before (see #2032 (comment)), but I'm wondering if things have changed since then.

[Niceplace]

Yay for Global timeout settings !

I'm not sure if this is the right place to discuss this but was wondering, are there any plans to add:

1. Implicit waits for common actions (click, fill) that check if an element meets the right conditions (present, visible, enabled or any combination of this) before interactinf with it.

2. The equivalent of page.waitForFunction() but instead of acting on javascript injected in the page, it acts as a polling function that one can use with any puppeteer objects (page, frame, etc.).

3. A polling function that expects something to be truthy / true for a fixed amount of time (e.g. a button has to be enabled for at least 5 seconds).

[Jamesernator]

I agree with @benjamingr , is there a reason for not using structured clone-like serialization rather than JSON serialization?

[jadell]

Will we ever see caching remain enabled even with request interception enabled?

[benjamingr]

@Jamesernator I ended up doing this on my own fork on top of puppeteer - this required non trivial changes in the inspector code in V8 and I am not confident in my ability to actually land those changes given how hard the process is. It did end up making for an interesting conference talk in DevDays.

I ended up creating an HTTP server and fetching from it from the page which is fast, alternatively passing strings is pretty fast. It's just a shame puppeteer doesn't do the right thing by default.

At least - it should warn.

[JoelEinbinder]

We are actually working on a binary devtools protocol in chromium that might help. Waiting for it to stabilizing before moving puppeteer on it though.

Can you file a separate issue instead of cluttering this one? Still interested in the exact use cases.

[benjamingr]

@JoelEinbinder sure, what would be the best way to collaborate with you or provide feedback on the binary devtools protocol? I am a pretty heavy devtools protocol (both using puppeteer, in Node on the inspector, using the cdp package and at my job Testim.io ).

I would love to participate in this. How do I get involved?

(Also, feel free to email me or suggest a communication channel more convenient to you, I am found at benji@testim.io - if you prefer my personal email that's available on https://github.com/nodejs/node)

[catalinberta]

Any plans to add touchstart/touchmove/touchend support in v2? But most importantly, touchmove to simulate swipes, not just clicks. I think this would be a good opportunity to rethink how we can simulate touchmove. A lot of code relies on this event, mouse events just won't do, we need mobile support to test various mobile only pages.

[webfolderio]

consider switching to pipes instead of websocket connection by default (not doing this - doesn't worth a hassle)

I know that WebSocket works as fast pipe but i don't understand why do you change your mind?

[jesse996]

one year ago..

[david-littlefield]

You guys are awesome! Thank you, for sharing such an incredible tool! =]

[Krinkle]

Apologies if this was considered already, but might I propose for 2.0 to (wherever possible) only remove deprecated options and aliases, and (where possible) for newer abilities and renames to actually be introduced in a late 1.x release.

I've seen this practice adopted elsewhere and tends to result in smoother adoption and upgrade experience, I think.

[mathiasbynens]

v2.0.0 is out, with a subset of the breaking changes in the top post. We've decided the other breaking changes are probably not worth the hassle right now.

[Janpot]

@mathiasbynens

We've decided the other breaking changes are probably not worth the hassle right now.

Maybe the ticket can be kept open and renamed to "v3.0 Breaking Changes"? I mean, I think I'm still interested in some of these issues.

[mathiasbynens]

@Janpot We can track this in separate tickets. Please file issues for any changes that seem worth it to you!

[Janpot]

@mathiasbynens FYI, I filed #5086

[benjamingr]

@mathiasbynens can this issue now be unpinned?

[mathiasbynens]

@Janpot Thanks!

@benjamingr Done.