1616211 - Wrong line for captured async frame

Status: NEW

(DevTools :: Debugger, defect, P3)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: image.png

STR:

1. Load https://relieved-cesium.glitch.me/
2. Create BP on line 19
3. Click the Click Me! button on the page, the debugger should pause
4. Check out the Call stack side panel, the line for frame onTestCaseStart is 4 => BUG

AR: The line for frame onTestCaseStart is 4

ER: The line for the frame should be 9 since that's where the (parent) function call happens.

Honza

Comment 1

[Logan Smyth [:loganfsmyth]]

Huh, this is an interesting case. I can see the argument for wanting to go with this approach, but it's definitely not what we do right now and I guess it's a question of expectation, and I could really go either way. Right now, the position used is the position where the callback is attached, not where the action that eventually asynchronously triggers the callback was initiated. Line 9 is what started the operation, but line 4 is where the callback was attached to the XHR object.

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: image.png

I created yet another test case here: https://changeable-dresser-sgpdrfz01.glitch.me/

It's very similar to the XHR test case except there are no XHR but, plain JS functions

In this case the line for the send function is correctly: 9
(i.e. not the location where the callback is attached)

Perhaps it's related to how XHR is internally implemented..?

In any case, I think that the expectation should be that both test cases work the same.

Honza

Comment 3

[Logan Smyth [:loganfsmyth]]

I think you're right about .send being a nicer location, but this does seem like it could be a large change, so I'd really have to dig into the infrastructure of captured stacks to potentially change this.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thank for looking at this Logan!

but this does seem like it could be a large change, so I'd really have to dig into the infrastructure of captured stacks to potentially change this.

Yep, I see. It would be nice to have this fixed but, it isn't a blocker for async captured stacks. So, we shouldn't spend significant time on this at this point (P3 seems appropriate for now)

Honza