Closed Bug 1131174 Opened 9 years ago Closed 9 years ago

ScriptStore isn't populated correctly

Categories

(DevTools :: Debugger, defect)

37 Branch
x86
macOS
defect
Not set
normal

Tracking

(firefox36 unaffected, firefox37 affected, firefox38 affected)

RESOLVED WORKSFORME
Tracking Status
firefox36 --- unaffected
firefox37 --- affected
firefox38 --- affected

People

(Reporter: jsantell, Unassigned)

References

Details

Attachments

(1 file)

STR
Go to: http://webaudiotool.com/app/?patch=1C170F35-3D45-0777-0EFF-8F3DFE42A3F1
Breakpoint on AudioContextManager.js, Line 54
Refresh

Aurora 37.0a2:
Breakpoint appears on the sources list as line 54, but in the source code, drops to the bottom (line 224)

Nightly 38.0a1 (Feb 9th 2015)
Before refreshing, even clicking the breakpoint at line 54 will automatically slide down to the bottom (line 224), with the sources list showing it as line 224 as well (rather than line 54 atleast, like aurora)
Summary: Breakpoints drop to bottom after reload → Breakpoints drop to bottom immediately/after reload
This seems to work fine in Beta 36
Depends on: 1132224
In current Beta (37) the breakpoint is still automaticaly falling down to the last line.
Another use-case here:
http://www.w3schools.com/angular/angular_application.asp
using file 'analytics.js' (it's a bit minificated but still on multiple lines)
1) load page
2) open dev. tools
3) open file 'analytics.js'
4) refresh screen
5) putting breakpoint anywhere will cause it's fall to the last line
I cannot believe this bug haven't been fixed yet. Currently it's present in the proper RELEASE version 37 which makes Firefox totally unusable for any debuging in our company since this bug is affecting all screens in our web application.
The title of this bug was pretty generic; the use case that we hit here was fixed. You found another unrelated problem.

The way we previously did breakpoint sliding was pretty broken. You are trying to set a breakpoint on a minified file, which is a weird thing to do, since none of the lines really make sense. I'd like to know what you do in your company that is broken; are you trying to set a breakpoint on minified obfuscated JS?

Either way, this has been fixed in Nightly and Dev Edition. We've completely refactored breakpoint sliding recently so it works a whole lot better. Sorry release is stuck with broken behavior right now; try Dev Edition to get a better experience. In a few months most of our fixes will be out in release.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Of course we are not debugging minified .js files. The problem is fully present in standard source files, no matter where I put the breakpoint. But since I cannot publish company source files, I was trying to find a public page where I was able to reproduce the problem and the minified file was the best I find.

This bug report was not marked as fixed and description, behavior and affected versions fully corresponds with my problem.

So fix won't be not even in beta channel? That sucks :(
It looks like Beta does not have the fix, sorry :( Dev Edition should be very stable; I would recommend trying it (if you don't like the dark them you can switch to the light theme).
Please reopen this bug, it is definitely not fixed in a released version. I have 37.0.1 and setting breakpoints on a non-minified .js file only works on a few lines, otherwise they slide to the bottom. 

I'm not even sure what a breakpoint at the bottom means, when will it be reached?
Flags: needinfo?(vp2177+mozbugz)
(In reply to Peter from comment #8)
> Please reopen this bug, it is definitely not fixed in a released version. I
> have 37.0.1 and setting breakpoints on a non-minified .js file only works on
> a few lines, otherwise they slide to the bottom. 
> 
> I'm not even sure what a breakpoint at the bottom means, when will it be
> reached?

This happens when there is no executable code within those lines to set a breakpoint on, but the reason it got that way depends on multiple factors. The original bug here was referencing a very specific case that we broke, so I'm changing the title.

Please file a new bug with a test case and we'll take a look.
Summary: Breakpoints drop to bottom immediately/after reload → ScriptStore isn't populated correctly
Nope.

I am sorry, I have tried creating a minimal testcase, however in the testcase, breakpoints work fine.

However, the issue is real and 100% reproducible with our production codebase, unfortunately I can't share that code.
It's a very large project using (things that might be relevant to this bug) ES5 shim, ES5 sham, Require JS for loading practically everything, no major framework, jQuery and D3 are used. 

The bug manifests in lines where Chrome can set breakpoints (and stops at them), however in Firefox the breakpoint "falls" to the bottom with an almost ironic animation. The JS files in question are loaded by Require JS from files themselves loaded via Require JS. If it is relevant there are usually at least 3000 JS files loaded. Only the Java plugin is embedded.

Previous versions of Firefox could also set breakpoints in the same places where it now can't.
Flags: needinfo?(vp2177+mozbugz)
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: