Closed
Bug 1131174
Opened 9 years ago
Closed 9 years ago
ScriptStore isn't populated correctly
Categories
(DevTools :: Debugger, defect)
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)
116.96 KB,
image/png
|
Details |
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)
Reporter | ||
Updated•9 years ago
|
Summary: Breakpoints drop to bottom after reload → Breakpoints drop to bottom immediately/after reload
Reporter | ||
Comment 1•9 years ago
|
||
This seems to work fine in Beta 36
status-firefox36:
--- → unaffected
status-firefox37:
--- → affected
status-firefox38:
--- → affected
Comment 3•9 years ago
|
||
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
Comment 4•9 years ago
|
||
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.
Comment 5•9 years ago
|
||
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.
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Comment 6•9 years ago
|
||
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 :(
Comment 7•9 years ago
|
||
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).
Comment 8•9 years ago
|
||
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)
Comment 9•9 years ago
|
||
(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
Comment 10•9 years ago
|
||
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)
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•