Boris Zbarsky [:bzbarsky] Reporter
	Description • 8 years ago

[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.  :(

	Brian Grinstead [:bgrins]
	Comment 1 • 8 years ago

Bryan, is adding conditional breakpoints being tracked?  I can't find any related issues on github.

	Marcia Knous [:marcia]
	Comment 2 • 8 years ago

Tracking 52+ for this issue.

	Brian Grinstead [:bgrins]
	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.

	Bryan Clark (DevTools PM) [:clarkbw]
	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.

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 5 • 8 years ago

And the tracking bug for the debugger on by default is bug 1294139

	Boris Zbarsky [:bzbarsky] 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...

	Bryan Clark (DevTools PM) [:clarkbw]
	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.

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 8 • 8 years ago

Here's the latest for conditional breakpoints: https://github.com/devtools-html/debugger.html/issues/101#issuecomment-256046076

	Bryan Clark (DevTools PM) [:clarkbw]
	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.

	Boris Zbarsky [:bzbarsky] 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.

	Boris Zbarsky [:bzbarsky] 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?

	Bryan Clark (DevTools PM) [: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.

	Boris Zbarsky [:bzbarsky] 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.  :)

	James Long (:jlongster)
	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.

	Julien Cristau [:jcristau]
	Comment 15 • 8 years ago

I guess that was it: https://hg.mozilla.org/mozilla-central/rev/affa5fe3fa4f

Updating status flags on that basis.