With the switch from JSM to ESM, we'd like to convert many existing "pseudo-private" members (prefixed with underscore, e.g. _methodName) in chrome UI classes to actual private members (e.g. #methodName). However, that currently has the downside of impeding casual tweaking/debugging/troubleshooting with the devtools, and also prevents us from using private members for methods/properties that are only accessed externally in automated tests, but might still like to be encapsulated in normal operation.

Idk how practical implementing some kind of bypass would be, but it would be really great to have some kind of bypass method or flag that could be set in certain contexts. For example, a browser test could call something like Services.scriptSecurityManager.allowJSPrivateAccess(true) to allow access to private members, at least within the current scope. And the browser toolbox could use the same method to add an "Allow private member access" checkbox to its meatball menu, or something along those lines.

There might be other alternative approaches to achieving the same end goal so lmk if you have any ideas or suggestions.

:mgaudet how practical would implementing this be?

It seems like it would be useful for debugging in general.

It's not certainly a simple thing.

The main challenge is how to correctly map a private name to the correct private symbol. From an implementation perspective, the name #x is mapped to a hidden Symbol, which is used as the property key on the object.

In the debugger (in some but not all circumstances see Bug 1702038) we're able to use the evalInFrame functionality to correctly map #x to the correct private name symbol. But if you're just poking at some object, there's no easy way to map the textual #x to the correct private name in general (consider class A { #x }; class B {#x}, how do you correctly choose which private name symbol for some arbitrary o.#x?).

A more robust, and useful for the web investment might be to instead fix Bug 1702038 and Bug 1759826, in general ensuring that private fields and methods have excellent and robust support through the debugger.

(In reply to Matthew Gaudet (he/him) [:mgaudet] | Out Until January 3, 2023 from comment #2)

A more robust, and useful for the web investment might be to instead fix Bug 1702038 and Bug 1759826, in general ensuring that private fields and methods have excellent and robust support through the debugger.

Unfortunately fixing those other bugs wouldn't really fix our issue, which is not being able to redefine private field values on the fly (in both manual and automated testing) the way we can for underscored values. It rules out sinon.JS which we currently use in automated tests to stub "pseudo-private" methods for example. So this is one of the things (possibly the only thing?) impeding adoption of private fields, which otherwise I would be excited to use. I imagine reassignment would be much more difficult to support than debugger access, but as you noted we already have bugs for the other issues

Supporting casual inspection is pretty much an explicit non-goal from the private fields language design; it was built to provide very high levels of privacy (arguably, as you're discovering, too high).

I'd argue that private fields don't bring terribly much value if you're working in a code base that has a lot of mutual trust, and would argue you should just keep using _ prefixing.

There's zero performance benefit in the engine for private fields.

Yeah I see what you mean. Thanks for taking the time to consider it anyway!