495134 - [jsd] No longer able to set breakpoints on lines within functions that have parameters

Status: RESOLVED DUPLICATE of bug 494954

(Core :: JavaScript Engine, defect)

Description

[Michael Kraft [:morac]]

I noticed today that breakpoints can no longer be set on the vast majority of lines where they should be settable.  This is easy to see using the JSD.  Simply open browser.js and scroll down.  At some point the "-" no longer shows up next to any lines other than function declarations.  For example no breakpoints can be set in the function "UpdateBackForwardCommands".

This problem started in the 20090523 trunk load and in the 20090527 1.9.1 branch load.  Cross referencing what went into each of those loads means one of the following caused the problem:

Bug 493260, bug 462704 or bug 493512.

Comment 1

[Brendan Eich [:brendan]]

Obvious candidate is bug 462704 -- can you test by backing out that fix? Or otherwise finding a build without it? Need to jump on this if it's as bad a regression as it sounds.

Is "the JSD" Venkman or Firebug?

/be

Comment 2

[Michael Kraft [:morac]]

I favored bug 462704 myself, but looking at 493260 and 493512, I couldn't eliminate them as possibilities as I don't know much about the core javascript code.

It would take me a while to build, unless you have a build without bug 462704 lying around.

I originally tested solely with Venkman, but I just tried adding breakpoints in Shiretoko 20090527 using Firebug 1.4X.0a30 at http://www.mozilla.org/projects/minefield/ and I'm seeing the same problem.  

I tried putting a few break points in http://www.mozilla.org/__utm.js. Breakpoints set in functions that have no parameters, such as _uDomain() work fine, bug breakpoints set in functions that have parameters, such as _uHash, do not work.  In addition those break points show as being in function "undefined" as opposed to the actual function name.

So the problem affects both Venkman and Firebug.  

Also it looks like breakpoints only fail to set on lines within functions that have parameters.

Comment 4

[Joe Drew (not getting mail)]

No need to ask for blocking on a duplicate.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

(actually not the right approach; if this is a straight dupe (which I don't think it is) then we clear the flag. if it's a similar symptom that is fixed by the dupe then we + it, so that if this turns out to not be entirely fixed by the dupe, it picks up blocking)

Comment 6

[Brendan Eich [:brendan]]

FWIW, it's a straight dup.

/be