STR: * unzip the attachment * load the index.html * open the debugger * look the Console, you see "log1" * look inside script.js * edit script.js, replace "log1" with "log2", save * click "reload frame" * see that the script.js panel content has not changed * see that the console now displays "log2" which proves the new content has been correctly parsed and executed Expected: the panel content changes Note1: This works fine in Firebug, and this works fine if it's not inside a frame. Note2: The bug happens both with file:// and http:// url. Blocking the gaia devtools bug because this is how the unit test runner is working and it makes it uneasy to debug using unit tests.

Hey Victor, if that's not too difficult, I'm willing to contribute a patch here, but I don't even know where to start. So if you can give me some pointers and maybe ideas, I can try to come up with something, because this really hurts my workflow :) Thanks!

At a first quick glance, I don't know how to fix this bug. Maybe :fitzgen would be a better mentor for this?

We need bug 905700 so that we can recognize that although it is the same url, it is a new source.

Any ETA ? ;)

This is a major issue for me trying to debug iframe intensive pages. Any fix in sight? or should I request a "work-around button" so we can manually update an iframe in the debugger or firebug.

Now that we have Debugger.Source, how hard would it be to fix this?

(In reply to Eddy Bruel [:ejpbruel] from comment #6) > Now that we have Debugger.Source, how hard would it be to fix this? I think the backend is in better shape to fix this, but now the main problem is the frontend caching script contents. If we still get a `newSource` notification for the new script, but it's the same URL, maybe we can blow away the current cache for its source contents. Right now we still don't have a way for the frontend to actually see that it's a new source instance. The way we did Debugger.Source treats scripts with the same URL across reloads as same scripts, to make it easy to think about breakpoints and other things that should live across reloads. But I don't see why we wouldn't get a `newSource` notification, and we should just check if we have source contents cached for that URL and blow it away if so.

Sorry to chime in, but this is really painful for Gaia development. How comes that Firebug works here but that we can't make it work with the Devtools?

(In reply to Julien Wajsberg [:julienw] (PTO -> Apr 27) from comment #8) > Sorry to chime in, but this is really painful for Gaia development. > How comes that Firebug works here but that we can't make it work with the > Devtools? I don't know how Firebug works with source contents at all, so I don't know. I don't think this is architecturally hard anymore, it's just a bug. I'll take a look and see if there's a quick fix.

So this is connected to the general problem that we don't update our cache if a source with the same URL is loaded multiple times. It's mainly a UX issue: what happens if you set a breakpoint on a source, reload the iframe so the source is updated with new text, but a breakpoint is hit in the old source? There will still be references to functions created from the old source. I know that's not quite the case here for iframes; reloading an iframe means blowing away the past state. But for updating a source's text is a more general event that can happen from several places, like eval'ing code with the same sourceURL. Need to think about this a little more.

Note that Chrome has this problem too; they don't update the source text. Need to think through the UX here.

The only possible quick fix I can think of right now is to introduce another config option (maybe hidden?) that updates the source contents when a new source comes in, *even if* one already exists with the same URL. The problem with switching that on by default right now is that it's more common to have breakpoints on existing scripts probably. The root of the problem is that we can only show the source of scripts that exist in the source listing, when we really should be more flexible. The source listing should show the URLs of current sources, but if a breakpoint is it, it shows that specific source (even if it's an older source of the same URL)

I'm not working on this right now, but I can look at it again soon

I definitely agree that a reload on the iframe needs to keep the breakpoint if the file is the same... and I'd even say even if the file is not the same we should try to keep the breakpoint at the same line. Maybe it will be wrong but at least this is somewhat consistent.

As a stop gap, could we have a manual update button? So an iframe gets reloaded, you are trying to debug it, but the debugger panel has not updated, so you click the new "Update" button that refreshes that panel with the correct code. Even if the breakpoints are lost, at least let us see the code and apply new breakpoints.

Noticed in nightly that there is a nifty new source tree for the debugger panel. Seems to load a source only after you click it, any way for this to show the code that is actually been reloaded? Also, it adds a panel for that source code, it would be great if it would open a new one with the reloaded code and keep the existing one for reference.