you want to debug your own code that calls into a library at various points and don't want to step through that alien code. The bug is in your stuff (you hope).
When debugging, it can be useful to "Step Around" library code. I.e., treat libraries as "Black Boxes" for the purposes of debugging. Use case: you want to debug your own code that calls into a library at various points and don't want to step through that alien code. The bug is in your stuff (you hope). Possible Implementation: It should be possible to implement this in the Debug Server by providing scripts that are known to be libraries. (UI could be a context menu on the sources to indicate that this is a library script) When running in Debug mode, when entering a frame, the Debug Server can check to see if this script url is one of the libraries and continue stepping until the current frame is in a different source url.
plus one that. I have been recently playing with jQuery a lot and debugging custom functions built around jQuery is a hell. Up to 10 stack frames on line 2 of jquery.min.js and then you finally press the step over button and miss the frame which you were actually looking into.
Is this bug restricted to blackboxing within the Debugger panel? If not, bug 1102797 should be blocking it. Sebastian
Sorry, wrong bug. The correct one is bug 905978. Sebastian
(In reply to Sebastian Zartner from comment #3) > Sorry, wrong bug. The correct one is bug 905978. > > Sebastian Yeah, this bug is restricted to blackboxing within the Debugger panel. But thank you very much for bringing that bug to my attention!
I mean, it seems like it makes sense to add that bug as a blocker just to keep it tracked, unless we want to add another meta meta blackboxing bug and start getting super bureaucratic and all that... Eddy?
(In reply to Nick Fitzgerald [:fitzgen] from comment #5) > I mean, it seems like it makes sense to add that bug as a blocker just to > keep it tracked, unless we want to add another meta meta blackboxing bug and > start getting super bureaucratic and all that... > > Eddy? I agree that we shouldn't be overly bureaucratic about these things, but I'm a bit worried that I'll lose overview of what bugs belong to the debugger if we also start tracking non-debugger stuff under these meta bugs. On the other hand, blackboxing is a feature that primarily belongs to the debugger. The fact that we sometimes need to make changes in closely related components doesn't really change that, so I guess it wouldn't hurt to add this bug as a blocker. If we run into more of these 'related' bugs in the future, let's decide on a case by case basis whether to add them to one of these meta bugs or not. Does that sound reasonable for now?