Closed
Bug 1307037
Opened 8 years ago
Closed 8 years ago
Conditional breakpoints no longer seem to exist
Categories
(DevTools :: Debugger, defect)
DevTools
Debugger
Tracking
(firefox51 unaffected, firefox52+ fixed, firefox53 fixed)
RESOLVED
FIXED
Firefox 52
Tracking | Status | |
---|---|---|
firefox51 | --- | unaffected |
firefox52 | + | fixed |
firefox53 | --- | fixed |
People
(Reporter: bzbarsky, Unassigned)
References
Details
[Tracking Requested - why for this release]: I don't see any way to make breakpoints conditional in the new UI that landed in bug 1300861 now that my nightly has updated to a build with that change... This is a pretty serious hindrance for doing Gecko work, unfortunately. :(
Comment 1•8 years ago
|
||
Bryan, is adding conditional breakpoints being tracked? I can't find any related issues on github.
Flags: needinfo?(clarkbw)
Comment 3•8 years ago
|
||
Worth noting that the new debugger frontend is currently Nightly only as of today so it wouldn't ride the train. But as far as I know, they are planning to make change this so it would ride with 52 to Dev Edition.
Comment 4•8 years ago
|
||
The old debugger should still be available. Are you working in the browser toolbox? It is supposed to be the default there. To return to the old debugger, open this in a new tab and set the pref to false: about:config?filter=new-debugger Reload browser. We don't have conditional breakpoints currently tracked as a blocker for the release beyond 52. We were hoping to rethink how they are done but we can review the blockers and possibly get a minimal implementation landed.
Flags: needinfo?(clarkbw)
Comment 5•8 years ago
|
||
And the tracking bug for the debugger on by default is bug 1294139
![]() |
Reporter | |
Comment 6•8 years ago
|
||
> Are you working in the browser toolbox?
No, in the web console.
I can certainly just disable the new debugger (and have done that so I can get my normal work done), but note that this means that I won't end up using the new debugger until the pref stops working or something, and therefore won't be able to provide feedback on it...
I do suspect pushing the current state out to devedition is likely to make developers stop using devedition, but maybe people just don't use conditional breakpoints as much as I think they do...
Blocks: 1294139
Comment 7•8 years ago
|
||
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #6) > I can certainly just disable the new debugger (and have done that so I can > get my normal work done), but note that this means that I won't end up using > the new debugger until the pref stops working or something, and therefore > won't be able to provide feedback on it... Lets setup a time to talk, it would actually be really good to understand how you're using conditional break points so as we implement them we could perhaps do a better job this time. > I do suspect pushing the current state out to devedition is likely to make > developers stop using devedition, but maybe people just don't use > conditional breakpoints as much as I think they do... Good question, we don't have metrics around these types of actions. I would suspect a low total usage, but DevEdition is most likely the place where it would be used.
Comment 8•8 years ago
|
||
Here's the latest for conditional breakpoints: https://github.com/devtools-html/debugger.html/issues/101#issuecomment-256046076
Comment 9•8 years ago
|
||
We're tight on time for landing in the 51 release so this might not make it. I want to see it land and get some testing in Nightly before we send it out to a broader audience. Removing from release requirements for now, we'll look into uplifting this once it has had some time in Nightly.
No longer blocks: 1294139
![]() |
Reporter | |
Comment 10•8 years ago
|
||
That seems... pretty backward. Or put another way, we should NOT be enabling the new debugger by default for all channels until this is fixed, because for any sort of serious use this functionality is absolutely indispensable.
![]() |
Reporter | |
Comment 11•8 years ago
|
||
Or put yet another way, how are you planning to ensure that this is fixed on release before bug 1294139 is fixed on release, if you removed the dependency?
Flags: needinfo?(clarkbw)
Comment 12•8 years ago
|
||
The old debugger is still available, precisely for the reason that we haven't completed all necessary features. This new debugger is much better and very different from the old, we need to get more feedback on those core changes. bug 1314057 is tracking the required work to remove the old debugger. I'm adding this to block that. Though, just to note, I believe this feature is already done and landing with the new debugger in nightly tomorrow.
Blocks: 1314057
Flags: needinfo?(clarkbw)
![]() |
Reporter | |
Comment 13•8 years ago
|
||
> The old debugger is still available, precisely for the reason that we haven't completed all necessary features Sure, that works for nightly, but for release (whatever that means in the case of debugger and its users; might be devedition in practice) that's not really enough unless you expect web developers to be digging up this hidden pref... > we need to get more feedback on those core changes Of course. Again, my question was about release and how we make sure we don't ship a serious functionality regression to our users. Making this block the removal of the old thing means nothing if the new thing is on by default and shipping to all users! > I believe this feature is already done and landing with the new debugger in nightly tomorrow Great. :)
Comment 14•8 years ago
|
||
FWIW, we have landed conditional breakpoints in the new debugger on github, and it will be available with the next debugger update in the next day or two. Marking this bug as fixed.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Comment 15•8 years ago
|
||
I guess that was it: https://hg.mozilla.org/mozilla-central/rev/affa5fe3fa4f Updating status flags on that basis.
status-firefox51:
--- → unaffected
status-firefox52:
--- → fixed
status-firefox53:
--- → fixed
Target Milestone: --- → Firefox 53
Updated•8 years ago
|
Target Milestone: Firefox 53 → Firefox 52
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•