Nowadays Javascript classes can have truly private properties and methods using the # prefix. We should use that instead of the current unenforced _ naming convention.

Depends on D161121

https://hg.mozilla.org/mozilla-central/rev/ca4db8d37ef9

Private members make it kinda hard to debug and experiment with stuff in the browser console. Before we convert a lot of these, could we consider the feasibility of allowing some kind of bypass in certain contexts? I imagine that'd be a spidermonkey thing if it's possible. Also I think Searchfox doesn't know how to parse private field names yet, so the sticky highlighter doesn't work on them

(In reply to Shane Hughes [:aminomancer] from comment #4)

Private members make it kinda hard to debug and experiment with stuff in the browser console. Before we convert a lot of these, could we consider the feasibility of allowing some kind of bypass in certain contexts? I imagine that'd be a spidermonkey thing if it's possible.

Good point and interesting idea. Could you please file a devtools or spidermonkey bug on this?

Also I think Searchfox doesn't know how to parse private field names yet, so the sticky highlighter doesn't work on them

And on this too? We do seem to have a component for Searchfox: https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&component=Searchfox

mgaudet provided some feedback on the debugging/testing issue, basically that adding a bypass would defeat the purpose of private fields so one might as well use underscore prefixing for that. In light of that, maybe we can reconsider adopting private fields in mozilla-central. I like the feature but I'm not sure if it adds enough value in chrome and module code to outweigh the drawbacks. But I'm interested to hear what you and other code owners think. Maybe there are some security benefits I'm not aware of. At first glance, if anything gets access to privileged JS execution (a virus using autoconfig files or marionette comes to mind), it could certainly do a lot worse than poking around the chrome frontend code, e.g. injecting a phishing or key logging frame script into every browser, that kind of thing. So I can't think of any benefits to protecting the frontend code from external access. If it was free of any drawbacks, then it couldn't hurt. More protection than necessary is better than less protection than ideal. But IMO losing access in the debugger and in automated tests (spying with sinon.JS, etc.) is a pretty big drawback