1709542 - Evaluating an expression with a private field access while paused in a class method throws

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nicolas Chevobbe [:nchevobbe]]

Steps to reproduce

1. Go to https://firefox-devtools-private-fields.glitch.me/
2. Open the console
3. In the page, click on the Create instance and pause button, this should pause
4. In the console, evaluate this.#secret

Expected results

A result ("mySecret") is displayed in the console

Actual results

The evaluation throws with:

Uncaught Error: private method calls aren't available in this context

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

Matthew, could you shine a light on what's happening?
The console is using https://searchfox.org/mozilla-central/rev/6371054f6260a5f8844846439297547f7cfeeedd/js/src/debugger/Frame.cpp#1866-1897 to do the evaluation, and I'm afraid I don't understand what's leading to https://searchfox.org/mozilla-central/rev/6371054f6260a5f8844846439297547f7cfeeedd/js/src/frontend/EmitterScope.cpp#1010-1030

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

So the story at this point: In Bug 1662559, Jason Orendorff and I changed the storage mechanism for private methods in order reduce the storage requirements of methods. Before that patch stack, each object with a private method was required to have slot for that method. So,

class A { 
  #x() { return 1; }
} 
var a = new Array(1000).fill(1).map(() => new A); 

would have each instance of A have a slot dedicated holding #x, consuming 1000 * slotSize of memory.

After those patches, instead, there is only one slot, held in the environment object corresponding to class A, which holds the reference to #x.

The problem is: Our current front end drops too much information, and is unable to reconstruct the correct location of #x in debugger frames.

This is surmountable, but I didn't consider it a blocker to landing the implementation of fields/methods.

I will spend some time this week trying to figure out the cost of hanging on to enough information to correctly make this work. As those comments hint at; we have most of the machinery required already, but there are few obstacles that remain.

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

(Side note: The error message is bad; originally I had intended to only disable this for private methods. However, it turns out that when we delazify a script inside a debugger eval, we don't have enough information to to disambiguate methods and fields, so I had to disable it for everything, and forgot to change the message)

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

Matthew, should we move that bug to the Javascript Engine component so it's tracked by your team?

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Bug 1709542 - Allow accessing private fields and acessor methods inside of Debugger.Frame.eval r?arai

Comment 6

[Matthew Gaudet (he/him) [:mgaudet]]

Yes; I'm about to put a patch up.

I'm going to duplicate this bug as well, as the same restriction is going to remain for private methods after this. I have a partial patch, but won't be able to work on it for a while

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4cbfc533db5c
Allow accessing private fields and acessor methods inside of Debugger.Frame.eval r=arai

Comment 8

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/4cbfc533db5c

Comment 9

[Daniel Cicas [:dcicas], Release QA]

Hello,

I can confirm that this issue is fixed on Fx Nightly 91.0a1(20210607214637), Fx 90.0b4 on Windows 10, ubuntu 18.04 and macOS 11.3.