profile
viewpoint

puppeteer/puppeteer 61828

Headless Chrome Node.js API

microsoft/playwright 13188

Node library to automate Chromium, Firefox and WebKit with a single API

hashseed/node-coverage-demo 30

Demo for collecting code coverage within Node.js

hashseed/gn-node 14

Node.js built with GN

hashseed/node 1

Node.js JavaScript runtime :sparkles::turtle::rocket::sparkles:

hashseed/tc39-notes 1

These are the notes I take at TC39 Meetings, with Markdown formatting

hashseed/CodeMirror 0

In-browser code editor

hashseed/node-core-utils 0

CLI tools for Node.js Core collaborators

hashseed/node-gyp 0

Node.js native addon build tool

issue commentbinaryage/cljs-devtools

Custom formatters are being removed from Chrome?

The non-sticky setting is already being rolled out with Canary. But it still needs to be cherry-picked into Chrome 84. Will do this next week.

tekacs

comment created time in 7 days

issue commentbinaryage/cljs-devtools

Custom formatters are being removed from Chrome?

I'm the engineer behind this change. I'd like to give some background.

You will have noticed that the intended removal was planned to be rolled out step by step. The first step being that the experimental setting no longer sticks, and has to be enabled for every DevTools session. We intentionally did not remove the feature at once. Feedback like the one provided here is what we have been looking for, so thank you for that.

As for the rationale for the original proposal: custom formatters are an experimental feature and also not part of any spec, so we were not sure whether it found any significant adoption. Unfortunately, it has a flawed design, which made it a part of several security exploits in the past.

I can see that custom formatters are being relied on. That's why I already reverted the first step. We will reconsider this issue and hopefully can come up with a solution that doesn't break your use case.

tekacs

comment created time in 10 days

issue openednodejs/node

Console output for class instance __proto__ seems wrong

Consider following code

class A {
    getA() { return 0; }
    constructor() {}
}
class B extends A {
    getB() { return 0; }
    constructor() { super(); }
}
console.log((new A()));
console.log((new A()).__proto__);
console.log((new A()).__proto__ instanceof A);
console.log((new A()).__proto__ instanceof Object);
console.log((new B()));
console.log((new B()).__proto__);
console.log((new B()).__proto__ instanceof B);
console.log((new B()).__proto__ instanceof A);

Node 14 produces:

A {}
A {}
false
true
B {}
B {}
false
true

This is wrong since (new B()).__proto__ is an instance of A. I guess the confusing part is that (new B()).__proto__.constructor is class B.

For reference, Chrome DevTools produces:

A {}
{constructor: ƒ, getA: ƒ}
false
true
B {}
A {constructor: ƒ, getB: ƒ}
false
true

created time in 16 days

push eventChromeDevTools/devtools-protocol

Tim van der Lippe

commit sha d0bcd8d145e409582e9fad9e4323f486dc9cb3eb

Update bug report guidance to point to CRBug This makes it clearer for developers that this repository solely hosts the type definitions for CDP and does not handle issues with regards to the implementation and definition of CDP.

view details

Yang Guo

commit sha b53777ce195cb8e5567195a36815d29219adff70

Merge pull request #209 from ChromeDevTools/bug-report-template Update bug report guidance to point to CRBug

view details

push time in 2 months

PR merged ChromeDevTools/devtools-protocol

Update bug report guidance to point to CRBug

This makes it clearer for developers that this repository solely hosts the type definitions for CDP and does not handle issues with regards to the implementation and definition of CDP.

+10 -14

0 comment

3 changed files

TimvdLippe

pr closed time in 2 months

CommitCommentEvent
more