Sources aren't listed if Debugger is the selected tool when toolbox first opens on a testcase with a script in html

NEW
Unassigned

Status

()

Firefox
Developer Tools: Debugger
P2
normal
2 years ago
a year ago

People

(Reporter: bgrins, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
STR:

* Open https://bug1240881.bmoattachments.org/attachment.cgi?id=8712417
* Open the toolbox with the debugger panel selected first (either via the keyboard shortcut or by selecting debuggger then closing and reopening toolbox)

Expected:

* I see a source pointing to https://bug1240881.bmoattachments.org/attachment.cgi?id=8712417 with the inline script

Actual

* "This page has no sources"

Note: this appears to be an intermittent problem, but I've seen it on both e10s and non-e10s.  If it's not triggering try adding a new tab with the same url and following the STR again.  I don't see any errors in the browse console when this happens.
(Reporter)

Comment 1

2 years ago
James, can you reproduce this?  I've seen it on two different computers now
Flags: needinfo?(jlong)
(Reporter)

Comment 2

2 years ago
Created attachment 8716498 [details]
rdp-log.png

Nothing interesting here.. looks like the backed is just not returning any sources
(Reporter)

Updated

2 years ago
Depends on: 1240881
(Reporter)

Comment 3

2 years ago
Including Eddy in needinfo to see if he might be be able to take it out of James' queue.  Eddy, can you reproduce this problem?  See any likely cause?  This isn't a frontend problem - the server side isn't returning any sources.
Flags: needinfo?(ejpbruel)

Updated

2 years ago
Assignee: nobody → ejpbruel
Flags: needinfo?(ejpbruel)
This looks like a GC problem to me.

The script you're using doesn't define any top-level functions. If you define at least one top-level function, the problem seems to go away. This is because each function has it's own script object. Moreover, top-level functions create a global binding, so these script objects are never garbage collected. Therefore, there will always be at least one script object that the debugger knows about referring to the appropriate source.

If you don't define any top-level functions, however, the top-level script is now the only script referring to the source, so the debugger can only find the source as long as the top-level script still exists. Unfortunately, the top-level script can be garbage collected at any time, unless the debugger is open. While the debugger is open, we store a strong reference to the top-level script in the script cache, which prevents the top-level script from being garbage collected, but as soon as you close the debugger, the script cache is destroyed as well.

My observations seem to confirm this: I can reproduce the problem if I close/reopen the debugger often enough, unless I add a top-level function definition to the script.
Flags: needinfo?(jlong)
Yep, what Eddy said sounds right. I think the confusing thing is that you would expect the HTML page would always be displayed, no matter what. Right now we only register it if a JS source is alive from it. We should make sure we always generate a source for the HTML page, even if it technically has no sources.

It's more understandable if a JS source does not appear, because it's not too hard to realize that it's been GCed. But it's definitely strange to see no sources at all.
(Reporter)

Comment 6

2 years ago
Note, I've now also seen this also on pages like cnn.com which have a bunch of sources with top level functions
(In reply to (Unavailable until 3-7) Brian Grinstead [:bgrins] from comment #6)
> Note, I've now also seen this also on pages like cnn.com which have a bunch
> of sources with top level functions

Weird... What were the exact steps you used to reproduce?
Flags: needinfo?(bgrinstead)
Tentatively assigning P3 to this, since it looks like expected behavior. Will up the priority if it turns out to be an actual bug.
Priority: -- → P3
(Reporter)

Comment 9

2 years ago
(In reply to Eddy Bruel [:ejpbruel] from comment #7)
> Weird... What were the exact steps you used to reproduce?

I'll keep an eye out to see if I can reliably reproduce but I've seen it only once or twice across probably hundreds of loads.  Basically, I'll be working in the console and then switch over to the debugger panel after loading cnn.com and no sources ever get shown
Flags: needinfo?(bgrinstead)
(In reply to (Unavailable until 3-7) Brian Grinstead [:bgrins] from comment #9)
> (In reply to Eddy Bruel [:ejpbruel] from comment #7)
> > Weird... What were the exact steps you used to reproduce?
> 
> I'll keep an eye out to see if I can reliably reproduce but I've seen it
> only once or twice across probably hundreds of loads.  Basically, I'll be
> working in the console and then switch over to the debugger panel after
> loading cnn.com and no sources ever get shown

That's rare enough that it makes this bug unactionable in practice. I'm trying to reduce the number of unactionable bug we have for the debugger, so do you mind if I close this?
(Reporter)

Comment 11

2 years ago
(In reply to Eddy Bruel [:ejpbruel] from comment #8)
> Tentatively assigning P3 to this, since it looks like expected behavior.
> Will up the priority if it turns out to be an actual bug.

I don't agree that it's not a bug or expected behavior from the user's point of view.  If it was by design then the source should either always show up or never show up, not behave randomly.
(In reply to (Unavailable until 3-7) Brian Grinstead [:bgrins] from comment #11)
> (In reply to Eddy Bruel [:ejpbruel] from comment #8)
> > Tentatively assigning P3 to this, since it looks like expected behavior.
> > Will up the priority if it turns out to be an actual bug.
> 
> I don't agree that it's not a bug or expected behavior from the user's point
> of view.  If it was by design then the source should either always show up
> or never show up, not behave randomly.

From the user's point of view, the source should always show up, of course. But as I explained in comment 4, there is no way to accomplish this with our current API: if the script that introduces the source is garbage collected, the debugger won't be able to find it. We can, and in fact do, prevent scripts from being garbage collected, but we can't maintain that guarantee while the debugger is closed. Never having the source show up is not an option either.

If you can think of a way to make this work in a way that more closely matches the user's expectation, let me know. In that case I'd agree that this bug should have higher priority.
(Reporter)

Comment 13

2 years ago
(In reply to Eddy Bruel [:ejpbruel] from comment #12) 
> If you can think of a way to make this work in a way that more closely
> matches the user's expectation, let me know. In that case I'd agree that
> this bug should have higher priority.

The plan in Comment 5 seems reasonable, specifically: "We should make sure we always generate a source for the HTML page, even if it technically has no sources.".  I don't know (a) how hard that would be, or (b) if it would allow you to set a breakpoint in the HTML source that could be hit on the next reload.  James, do you have any ideas about that?
Flags: needinfo?(jlong)
(In reply to (Unavailable until 3-7) Brian Grinstead [:bgrins] from comment #13)
> (In reply to Eddy Bruel [:ejpbruel] from comment #12) 
> > If you can think of a way to make this work in a way that more closely
> > matches the user's expectation, let me know. In that case I'd agree that
> > this bug should have higher priority.
> 
> The plan in Comment 5 seems reasonable, specifically: "We should make sure
> we always generate a source for the HTML page, even if it technically has no
> sources.".  I don't know (a) how hard that would be, or (b) if it would
> allow you to set a breakpoint in the HTML source that could be hit on the
> next reload.  James, do you have any ideas about that?

I agree. That's at least something we should investigate. Upping the priority to P2, since this is essentially a UI papercut.

The main implementation challenge with this approach that I can see is this: currently, we obtain the URL of a HTML page with inline scripts from the corresponding Debugger.Script instance. If there are no such instances (because they have all been gc'd), how can we tell the URL of the HTML page to be displayed?
Priority: P3 → P2
Surely there's a platform API to get the URL of the current target if it's a tab, and we could use that. This would take some time to figure out, but probably not too hard. I'd estimate ~2 weeks to get it fully landed, and that might be optimistic. That part of the server code is pretty complicated.

You could set breakpoints on it because they would become "pending" breakpoints, and when the page is reloaded it will set the breakpoint at the right locations.
Flags: needinfo?(jlong)
(Reporter)

Updated

2 years ago
Depends on: 1254613
Assignee: ejpbruel → nobody
You need to log in before you can comment on or make changes to this bug.