Closed Bug 800200 Opened 12 years ago Closed 10 years ago

rm JSD

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla33
Tracking Status
firefox31 --- wontfix
firefox32 + wontfix
firefox33 --- fixed
relnote-firefox --- 33+

People

(Reporter: dmandelin, Assigned: jimb)

References

(Depends on 2 open bugs)

Details

(Keywords: addon-compat, dev-doc-complete, Whiteboard: [firebug-p1])

Attachments

(5 files, 4 obsolete files)

jsdbg2 obviates JSD, but there are things we need to do before actually removing JSD. First, Firebug has to be ported to jsdbg2. Honza listed some bugs he needs before he can finish that, which I attached here.

Getting this bug done soon enough would mean we didn't have to do bug 791062. That's not particularly likely, and that's OK.
\o/
Whiteboard: [firebug-p1]
Depends on: 637572
Depends on: 957798
No longer depends on: 911721
With the landing of bug 935203, I think we're about ready to delete JSD. The Firebug team has been actively migrating Firebug over to Debugger, and that work is essentially done (modulo one question; see the bug).

There are still a dozen or so AMO extensions out there, with audiences of varying sizes, that are currently using the old "@mozilla.org/js/jsd/debugger-service;1" component. I think this means that we should follow the usual XPCOM component deprecation schedule, and let those changes ride the trains, before we dump JSD.

Kris, what's the best way to get this started?
Keywords: addon-compat
Flags: needinfo?(kmaglione+bmo)
There are four things I think we need to do to make this happen:

1) Display a deprecation warning warning in the Error Console when the old debugger API is used. I'm not sure who the best person to handle this is, but the nearest examples I can think of to what we need are http://mxr.mozilla.org/mozilla-central/source/dom/src/json/nsJSON.cpp#49 and http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#1626

2) Send an email to authors of extensions on AMO which use the old debugger API, explaining that they need to update to use the new one, and linking to related docs. I can handle this if you file a bug.

3) Add a warning to the AMO add-on validator that the jsdI* interfaces, and the debugger-service contract, are deprecated. Please file a bug in the addons.mozilla.org > Add-on Validation component.

4) Add a warning to the AMO compatibility validator, as in #3, but this does not need to happen until the removal hits beta.
Flags: needinfo?(kmaglione+bmo)
The last necessary API (to remove JSD1) landed in 30 (note that there is still open discussion in Bug 935203) and it would be great if JSD1 based working Firebug (1.12) overlaps with JSD2 based working Firebug (2.0) at least for two Firefox versions. So, it would be great if JSD1 is still in 31 with no issues. This would give the Firebug team some time to catch after-release reported issues (so we can always point the users to working Firebug 1.12).

(not sure what is the schedule for AMO warnings and final removal)

Honza
(In reply to Jan Honza Odvarko from comment #4)
> The last necessary API (to remove JSD1) landed in 30 (note that there is
> still open discussion in Bug 935203) and it would be great if JSD1 based
> working Firebug (1.12) overlaps with JSD2 based working Firebug (2.0) at
> least for two Firefox versions. So, it would be great if JSD1 is still in 31
> with no issues. This would give the Firebug team some time to catch
> after-release reported issues (so we can always point the users to working
> Firebug 1.12).
> 
> (not sure what is the schedule for AMO warnings and final removal)

31 is an ESR, though... :-(
(In reply to Jim Blandy :jimb from comment #2)
> With the landing of bug 935203, I think we're about ready to delete JSD.

\o/ \o/ \o/
(In reply to :Gijs Kruitbosch from comment #5)
> 31 is an ESR, though... :-(

How feasible would it be to backport the necessary JSD2 changes to 29 so the two-version-overlap is possible?
(In reply to Florian Bender from comment #7)
> (In reply to :Gijs Kruitbosch from comment #5)
> > 31 is an ESR, though... :-(
> 
> How feasible would it be to backport the necessary JSD2 changes to 29 so the
> two-version-overlap is possible?

We're late in 29's Aurora lifetime... so I'm skeptical about uplifting core JS/JSD2 changes, but I'm also not the right person to ask. Jim?
Flags: needinfo?(jimb)
It's unforu(In reply to :Gijs Kruitbosch from comment #8)
> We're late in 29's Aurora lifetime... so I'm skeptical about uplifting core
> JS/JSD2 changes, but I'm also not the right person to ask. Jim?

Since it's new "plumbing" (adding new APIs, and then adding uses of those new APIs), it's not well-localized. It also ended up depending on bug 332176, which touched a bunch of stuff. I think if it's not urgent, we shouldn't carry it forward.

As much as I am looking forward to deleting JSD, we've been living with it for a decade, so we can wait another rapid release cycle if that makes the process go more smoothly.
Flags: needinfo?(jimb)
(In reply to Jim Blandy :jimb from comment #9)
> It's unforu(In reply to :Gijs Kruitbosch from comment #8)
> > We're late in 29's Aurora lifetime... so I'm skeptical about uplifting core
> > JS/JSD2 changes, but I'm also not the right person to ask. Jim?
> 
> Since it's new "plumbing" (adding new APIs, and then adding uses of those
> new APIs), it's not well-localized. It also ended up depending on bug
> 332176, which touched a bunch of stuff. I think if it's not urgent, we
> shouldn't carry it forward.
> 
> As much as I am looking forward to deleting JSD, we've been living with it
> for a decade, so we can wait another rapid release cycle if that makes the
> process go more smoothly.

No, my point was that if we want to have it deprecated (ie coming with warnings) and JSD2 ready for Firebug use for 2 cycles, we can't remove it before we hit ESR unless we uplift warnings (and making all the necessary fixes) to 29, which means we get to lug it around for another half year after that. I'm all for removing it sooner rather than later, but it doesn't look like it'd be feasible to avoid shipping it in 31-ESR.
I think I'd prefer for it to stay in the next ESR, with deprecation warnings, then rush to remove it beforehand. I doubt that it will be a huge maintenance burden in ESR (correct me if I'm wrong), and it would give users of existing code a bit longer to come up with solutions after it disappears from mainline releases.
(In reply to Kris Maglione [:kmag] from comment #11)
> I think I'd prefer for it to stay in the next ESR, with deprecation
> warnings, then rush to remove it beforehand. I doubt that it will be a huge
> maintenance burden in ESR (correct me if I'm wrong), and it would give users
> of existing code a bit longer to come up with solutions after it disappears
> from mainline releases.

It is a very annoying maintenance burden, and may prevent or hinder the backport of patches to that ESR, FWIW. But it sounds like we can't do anything about it.
If we land deprecation warnings for JSD in Mozilla Central now, then they'll appear in FF30. We'll be able to remove JSD from Mozilla Central after FF30 goes to Aurora on March 17. The public will have official releases supporting JSD until FF31 becomes the release on July 22. That's five more months of supported JSD; or four months for people running beta. That seems long enough to me.

So, what I'd like to do is:
1) Land warnings printed to the console when JSD is used in M-C now.
2) Remove JSD once Mozilla Central becomes FF31 --- so, shortly after March 17.
(In reply to Bobby Holley (:bholley) from comment #12)
> It is a very annoying maintenance burden, and may prevent or hinder the
> backport of patches to that ESR, FWIW. But it sounds like we can't do
> anything about it.

Bobby, I was just about to say the opposite --- it's been there for twelve years, and it's not accessible to content, so I would guess it's not the kind of thing that attracts much ESR-like attention. What sort of patches do we lift to ESRs that JSD impedes?

(Either way, landing the warning now is the next step...)
(In reply to Jim Blandy :jimb from comment #14)
> Bobby, I was just about to say the opposite --- it's been there for twelve
> years, and it's not accessible to content, so I would guess it's not the
> kind of thing that attracts much ESR-like attention. What sort of patches do
> we lift to ESRs that JSD impedes?

JSD hooks into XPConnect in all kinds of nasty ways, and it's not uncommon that I have to do extra work in JSD for system-wide architectural changes. Once JSD is gone, we're invariably going to make changes that would have broken it, and trying to code up JSD support at backport time is going to impose a lot of stop-energy. In some cases, that stop-energy will be significant enough that we'll end up just WONTFIXing the bug for ESR (and embargoing it if it's s-s).

If we can kill JSD before ESR, we absolutely should.
(In reply to Bobby Holley (:bholley) from comment #15)
> If we can kill JSD before ESR, we absolutely should.

Okay. Then let's make comment 13 the plan of record, then. That has JSD gone in 31.
(In reply to Jim Blandy :jimb from comment #16)
> (In reply to Bobby Holley (:bholley) from comment #15)
> > If we can kill JSD before ESR, we absolutely should.
> 
> Okay. Then let's make comment 13 the plan of record, then. That has JSD gone
> in 31.

I understand that everyone is happy to remove JSD1 (including me) and Firebug team has been working hard to make this possible, but it's not effective strategy to hurry just at the end when the platform is *almost* ready.

The bug 935203 has been marked as fixed, but there are still open questions about how to properly design JSD2 API for debugging dynamically created scripts (you can see bug 935203 comment 47 and bug 935203 comment 49).

There is also one follow up that actually suggests *changing* the new API (the new API Firebug needs to finish JSD2 adoption) for debugging dynamic scripts (debugging dynamically created scripts is the last missing piece Firebug team has been waiting for).

See Bug 977255 - [jsdbg2] Dynamic scripts should not have false URLs

Even if all the stuff lends in Firefox 30 (and I very believe so), there should still be an overlap of working JSD1 (no warnings that would frighten users) and JSD2 for two cycles. The amount of changes done in Firebug as part of JSD2 adoption has been enormous and we need some time to catch possible issues and use Firebug based on JSD1 as fallback.

> So, what I'd like to do is:
> 1) Land warnings printed to the console when JSD is used in M-C now.
> 2) Remove JSD once Mozilla Central becomes FF31 --- so, shortly after March
So, I think this is too soon. The warnings should land in 32 and JSD1 removed in 33. But we should really decide when Firebug based on JSD2 is done, released and we have enough feedback about how it works.

We have been all waiting for a long time and we should be still patient for a little while. Don't get me wrong, I would be happier to remove JSD1 much sooner!

Honza
I think that the deprecation warnings should go in as soon as possible, no matter when we decide to actually remove the JSD, to give developers as much lead time as possible to migrate. If users are forced to use an old version of Firebug, they should be prepared to deal with the warnings.
Even if the JSD code changes can't be uplifted to Aurora 29, could just the deprecation warnings be uplifted? I imagine the warnings changes would be pretty safe and uplifting them would give us an extra six weeks of deprecation warning.
Possible but the message must be hard-coded to avoid string change.
https://tbpl.mozilla.org/?tree=Try&rev=f6c2bf91927d

If we should use a non-localized message, I'm happy to revise this.
Assignee: general → jimb
Status: NEW → ASSIGNED
Here's one that doesn't include any localized text.

https://tbpl.mozilla.org/?tree=Try&rev=7e134c940b73
Attachment #8383961 - Attachment is obsolete: true
Attachment #8383993 - Flags: review?(bobbyholley)
Comment on attachment 8383993 [details] [diff] [review]
Print a deprecation warning to the console when JSD is first used.

Review of attachment 8383993 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with comment addressed.

::: js/jsd/jsd_xpc.h
@@ +292,5 @@
>      nsCOMPtr<jsdICallHook>      mTopLevelHook;
>      nsCOMPtr<jsdICallHook>      mFunctionHook;
>      nsCOMPtr<jsdIActivationCallback> mActivationCallback;
> +
> +    static bool sWarnedAboutDeprecation;

The JSD service is a singleton, so we should make this a member variable.
Attachment #8383993 - Flags: review?(bobbyholley) → review+
(In reply to Chris Peterson (:cpeterson) from comment #20)
> Even if the JSD code changes can't be uplifted to Aurora 29, could just the
> deprecation warnings be uplifted? I imagine the warnings changes would be
> pretty safe and uplifting them would give us an extra six weeks of
> deprecation warning.
Please no. Of course this would cause bad reputation for Firebug, since it would be the source of warnings and there is not other (JSD2 based) alternative for Fx 29.

Honza
(In reply to Jan Honza Odvarko from comment #25)
> Please no. Of course this would cause bad reputation for Firebug, since it
> would be the source of warnings and there is not other (JSD2 based)
> alternative for Fx 29.

I definitely don't want to hurt Firebug's reputation.

I don't feel that I understand Firebug's release process well enough to see how the choices we make affect you folks. Let's talk on IRC tomorrow morning, so that I can get a basic idea of how things work for you, and assess consequences better.
(In reply to Jim Blandy :jimb from comment #26)
> (In reply to Jan Honza Odvarko from comment #25)
> > Please no. Of course this would cause bad reputation for Firebug, since it
> > would be the source of warnings and there is not other (JSD2 based)
> > alternative for Fx 29.
> 
> I definitely don't want to hurt Firebug's reputation.
> 
> I don't feel that I understand Firebug's release process well enough to see
> how the choices we make affect you folks.
I think I described it in comment 18

The main goal is to always have working combo Firebug - Firefox.
And since JSD1 -> JSD2 step is big change, there should also
be an overlap where both Firebug versions are working with the same
version of Firefox (I was suggesting one or two Fx cycles in comment 18)

So at some point both: Firebug 1.12 (JSD1) + Firebug 2.0 (JSD2)
should be working on the same Fx release (no warnings that would scare users)

> Let's talk on IRC tomorrow
> morning, so that I can get a basic idea of how things work for you, and
> assess consequences better.
OK

Honza
Asking for an overlap without any warnings so that you can tell users to use an older version of Firebug is not reasonable. If users already know they're using an old version of Firebug, they should deal with the warnings. Other developers are going to need as much warning as possible that they need to migrate to the new API. They're not all as well-informed as you are.
(In reply to Jan Honza Odvarko from comment #25)
> Please no. Of course this would cause bad reputation for Firebug, since it
> would be the source of warnings and there is not other (JSD2 based)
> alternative for Fx 29.

The warnings are only logged to the console the first time jsdIDebugger::asyncOn is called. If I added an 'acknowledgeDeprecation' method to jsdIDebugger, which Firebug could call to disable the warning, would this make it acceptable to the Firebug team for us to uplift the warning to 29? Here's what I have in mind:

    /**
     * Suppress console warnings about using JSD, which is a deprecated API.
     *
     * This applies only to the next call to asyncOn; any subsequent calls
     * will elicit the warning, unless you call 'acknowledgeDeprecation'
     * before each of them, too. This arrangement ensures that one add-on's
     * acknowledgement doesn't suppress warnings for other add-ons.
     */
    void acknowledgeDeprecation();
Revised per review comments, and added an 'acknowledgeDeprecation' method, in case that will make it more palatable to Firebug. Enough has changed relative to the total size of the patch that I'm asking for review again, especially since we want to uplift this.

Try push:
https://tbpl.mozilla.org/?tree=Try&rev=00c12d8495ed
Attachment #8383993 - Attachment is obsolete: true
Attachment #8385653 - Flags: review?(bobbyholley)
Comment on attachment 8385653 [details] [diff] [review]
Print a deprecation warning to the console when JSD is first used.

Review of attachment 8385653 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/jsd/jsd_xpc.h
@@ +299,5 @@
> +    // We only ever print the warning once.
> +    bool mWarnedAboutDeprecation;
> +
> +    // True if the next call to asyncOn should not produce a warning,
> +    // because the user called jsdIDebuggerService::acknowledgeDeprecation.

s/user/consumer/.
Attachment #8385653 - Flags: review?(bobbyholley) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/e2db166682ac
Whiteboard: [firebug-p1] → [firebug-p1][leave open]
(In reply to Kris Maglione [:kmag] from comment #28)
> Asking for an overlap without any warnings so that you can tell users to use
> an older version of Firebug is not reasonable. If users already know they're
> using an old version of Firebug
The thing is that there is no new and old version of Firebug yet. There is still only 1.12 JSD1 based Firebug. And the version-in-progress (based on jsd2) is blocked by:

It's not clear how dynamic script will deal with URLs - will they stay as they are implemented now, or will be the same as the parent page or will be removed entirely and undefined, and how the stack trace will look like then - and in what Firefox version these changes would happen. See bug 957798 and bug 977255 (marked also as blockers of this report)

The Firebug team has been waiting for 6 months to get the last piece of API (debugging dynamically evaluated scripts in particular - Debugger.Script.introductionType, Bug 935203) to finish JSD2 adoption and now it can't even have a time to properly finish the adoption and test that all necessary platform API are ready.

Honza
(In reply to Jan Honza Odvarko from comment #33)
> The thing is that there is no new and old version of Firebug yet. There is
> still only 1.12 JSD1 based Firebug. And the version-in-progress (based on
> jsd2) is blocked by:

I don't have anything in particular to say about the timeline for removal of JSD1. All I'm saying is that we need to give developers deprecation warnings as soon as possible. As you say, you've had a lot of time to prepare and you're still not entirely ready. And given the clear maintenance burden of JSD1, we obviously can't afford to put off removing it for much longer.
With the patch I proposed, Firebug can continue to use JSD1 without eliciting warnings, so it should be fine to uplift.
(In reply to Jan Honza Odvarko from comment #33)
> It's not clear how dynamic script will deal with URLs - will they stay as
> they are implemented now, or will be the same as the parent page or will be
> removed entirely and undefined, and how the stack trace will look like then
> - and in what Firefox version these changes would happen. See bug 957798 and
> bug 977255 (marked also as blockers of this report)

Yes, the API is still in flux. But my intention was to give Firebug the information without which it cannot function, and then continue improving things after the release --- I hope it's not necessary to have everything perfect and frozen for Firebug to make the transition to Debugger. The nature of the problem means that, while the general outline is pretty much set, there will continue to be change for a while.

Here is how I imagined things would proceed:

- The first Debugger-based Firebug would continue to use a mix of the remote protocol and direct Debugger access, as it does now. The areas of Debugger that were still in flux could be worked around with techniques like those proposed in bug 935203 comment 60. Firebug would depend on close communication with the platform group to know which things could be depended upon.

- The protocol would then evolve to better support dynamic code. As it did so, Firebug would depend less and less on direct Debugger access, and more and more on the remote protocol.

- The Debugger API would mature --- say, the 'url' property's behavior would change. As it did so, Firebug could replace work-arounds and monkey-patches with code intended to be retained in the long term.

> and
> now it can't even have a time to properly finish the adoption and test that
> all necessary platform API are ready.

Firebug can have time to properly finish the adoption.

One thing that isn't clear to me is: if we remove JSD in FF31, it will be July before the released FF lacks JSD. Why isn't that enough time? (I do *not* mean that in the sense of "What's taking you so long???" - as you point out, it's taken me a long time to get around to something that I'd said was easy, so I'm not in a position to criticize anyone in that way. It is, rather, simply a sincere question: why is five months not enough buffer time?)
I'm interested in hearing your responses to the above, but here are more specific questions that might be helpful:

- When you announce a Firebug release, do you usually describe it as working against the current Firefox *release* (that is, code three months removed from mozilla-central), or does a Firebug release claim to work against all of the concurrent Aurora, Beta, *and* release of FF?

- Are you comfortable shipping a Firebug that uses both the protocol and direct Debugger access, or do you require the protocol to be far enough along that it can function without any direct Debugger access?
Comment on attachment 8385653 [details] [diff] [review]
Print a deprecation warning to the console when JSD is first used.

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
We need to warn add-on developers that the JSD debugging component is now deprecated.

User impact if declined: 
The developers of roughly a dozen add-ons will have six weeks less warning time before an API on which their add-ons depend disappears. 

Testing completed (on m-c, etc.): Yes.

Risk to taking this patch (and alternatives if risky): 
Very little. It just adds code to log a warning message to the console.

This is an innocent change. It's sweet and kind, and has large eyes welling with tears of gratitude.

String or IDL/UUID changes made by this patch:
jsdIDebuggerService has a new UUID. The console message is not localized.
Attachment #8385653 - Flags: approval-mozilla-aurora?
Attachment #8385653 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
One more question for Honza: Does the 'acknowledgeDeprecation' method described in comment 29 address your concerns about uplifting the deprecation warning to 29?
(In reply to Jim Blandy :jimb from comment #37)
> (In reply to Jan Honza Odvarko from comment #33)
> > It's not clear how dynamic script will deal with URLs - will they stay as
> > they are implemented now, or will be the same as the parent page or will be
> > removed entirely and undefined, and how the stack trace will look like then
> > - and in what Firefox version these changes would happen. See bug 957798 and
> > bug 977255 (marked also as blockers of this report)
> 
> Yes, the API is still in flux. But my intention was to give Firebug the
> information without which it cannot function, and then continue improving
> things after the release ---
I understand the intention and it's correct. But the time needed to get the
**introductionType** was far from what I was expecting.
The timing should not be: give it 6 months, introduce a new API and
remove the old one immediately. It should be: introduce a new API,
give it 6 months and remove the old one immediately.

So, we have time for testing and feedback. The API could have been better 
and number of future changes smaller (yes thinking about URLs), which usually
safes reasonable amount of time on extension development side.

I understand that implement new API takes time and that's why I have been
patient all the time. This is a feedback, I'm also not and I don't want
to be in a position to criticize anyone.

> I hope it's not necessary to have everything
> perfect and frozen for Firebug to make the transition to Debugger.
> nature of the problem means that, while the general outline is pretty much
> set, there will continue to be change for a while.
Sure, I have never expected to have all API perfect and frozen since the
beginning.

> Here is how I imagined things would proceed:
> 
> - The first Debugger-based Firebug would continue to use a mix of the remote
> protocol and direct Debugger access, as it does now.
Agree, and this is exactly the plan I have in mind.

> The areas of Debugger
> that were still in flux could be worked around with techniques like those
> proposed in bug 935203 comment 60.
I might be missing something, but I don't understand much how this
(bug 935203 comment 60) should change things.

As I already mentioned in bug 935203 comment 66 the problem is not to
distinguish a dynamic script (now when we have the introductionType) and so
generate unique URLs on the client side is simple. The real problem is
that the debugger does *not* know about these unique client side URLs and
continues using its own broken versions. This means that: all stack frames
sent back to the client are still wrong and dealing with breakpoints
(breakpoints also depend on URL) is a lot harder. Btw. in case of unique
script URLs, it would be a lot easier to reuse the existing BreakpointActor.


> Firebug would depend on close
> communication with the platform group to know which things could be depended
> upon.
I am personally doing that all the time. Note that my experience is that it
usually works this way (again, please take it as a feedback):
1) Firebug team finds a problem and reports it in bugzilla.
2) If the problem is directly reproducible in DevTools, it gets attention
 (one example: Bug 978019)
3) If the problem isn't interesting for DevTools, it never gets any
attention (one example: Bug 797876, btw. this one is also set as a blocker
of JSD1 removal (!), no attention, reported in 2012).


> - The protocol would then evolve to better support dynamic code. As it did
> so, Firebug would depend less and less on direct Debugger access, and more
> and more on the remote protocol.
Agree. Note that Firebug wants to use RDP to solve e10s.


> - The Debugger API would mature --- say, the 'url' property's behavior would
> change. As it did so, Firebug could replace work-arounds and monkey-patches
> with code intended to be retained in the long term.
Agree, that's what Firebug has always been doing.


> > and
> > now it can't even have a time to properly finish the adoption and test that
> > all necessary platform API are ready.
> 
> Firebug can have time to properly finish the adoption.
> 
> One thing that isn't clear to me is: if we remove JSD in FF31, it will be
> July before the released FF lacks JSD. Why isn't that enough time? (I do
> *not* mean that in the sense of "What's taking you so long???" - as you
> point out, it's taken me a long time to get around to something that I'd
> said was easy, so I'm not in a position to criticize anyone in that way. It
> is, rather, simply a sincere question: why is five months not enough buffer
> time?)
Indeed, 5 months is definitely a lot of time! But that isn't the time we
actually have. By the time Firefox is in its release phase, working Firebug
(JSD2) version must be already long time ready.

Your other question is the same, so copying it here:
> - When you announce a Firebug release, do you usually describe it as working
> against the current Firefox *release* (that is, code three months removed
> from mozilla-central), or does a Firebug release claim to work against all
> of the concurrent Aurora, Beta, *and* release of FF?
Firebug release claim to work against, Release, Beta, Aurora and we also need
to have working version for Nightly.

How it's been recently proved (Bug 977078 - Firebug stops working in Nightly30a1),
there are many people using Firebug in Nightly too.
Just after a few day of not having any release that would work for Nightly and
after it's been already reported and fixed in our issue list, we have got further
5 duplicate reports asking for a fix. Apart from that, other people where asking
me directly what version to use.

The release process/status:
1) The public release on AMO is now 1.12.7
It's now working also on Nightly and it's being maintained till next major
version is out. It's based on JSD1

2) The current version in development is 1.13 alpha 9 
Compatible with Release, Beta, Aurora, Nightly. It's fixing many problems and
implementing new features that will be part of the next major release.
This is also based on JSD1

3) The JSD2 based version (cloned from and regularly synced with #2)
Compatible with Nightly only (since needs all the new JSD2 API).
This is where all the development happens currently.


As soon as #3 is ready we'll merge into #2. We'll also take the opportunity
and call it Firebug 2.0
At this point all necessary Firebug features must work, to make sure all
needed platform API are in (Fx30) and there is no catch we forgot to cover by
a bugzilla report. To do so, we have roughly couple of weeks (31 released 2014-03-18).


In the meantime, we still need to maintain #1 - until Firefox 30 (the minimum
requirement for #3) is released. And as soon as 2.0 is out Firebug 1.12 should
still work (as I already mentioned). Now it seems that Fx 30 i.e. 6 weeks of
overlap is all Firebug has in case of problems (might sound as plenty
of time).


> simply a sincere question: why is five months not enough buffer time?)
Just to note, Firebug has roughly 10-12 months (from now) to get e10s ready,
which should be done by fully supporting RDP. This means having *every*
panel remotable.

And as indicated, we'll have to spend time by refactoring code
support again and again (since API changes, yes I know) while *keeping* compatibility
with previous Fx releases at the same time.


> - Are you comfortable shipping a Firebug that uses both the protocol and
> direct Debugger access,
> or do you require the protocol to be far enough
> along that it can function without any direct Debugger access?
Firebug is working around the protocol a lot, because there are many missing features,
Firebug needs to support. It's ok for now, but not for e10s and after that happens
Firebug will be fully dependent on the protocol (*heavily* dependent on having mainly
Bug 977443 and Bug 797639, plus things we can find during the process).


> One more question for Honza: Does the 'acknowledgeDeprecation' method described
> in comment 29 address your concerns about uplifting the deprecation warning to 29?
I didn't test the API yet, but if introduced deprecation API can be
disabled again - and so, folks are not stopping using Firebug because there are
weird and worrying warnings - it sounds ok (it's already there anyway).


Honza
Honza, how early can the jsd2-based firebug be released?

Adding drag to the spidermonkey for the entire ESR31 cycle is a pretty big pain.  We need to consider the possibility of having a nightly/aurora/maybe-even-beta cycle which is incompatible with Firebug if it means our engine developers can move faster.
(In reply to Jan Honza Odvarko from comment #41)
> > - When you announce a Firebug release, do you usually describe it as working
> > against the current Firefox *release* (that is, code three months removed
> > from mozilla-central), or does a Firebug release claim to work against all
> > of the concurrent Aurora, Beta, *and* release of FF?
> Firebug release claim to work against, Release, Beta, Aurora and we also need
> to have working version for Nightly.

I see. This was not something that I had previously understood. So, the six-week cycles of the Firefox release schedule do not actually give Firebug any breathing room, because a Firebug release is meant to be immediately usable on all four branches of Firefox.

That's... discouraging. Hmm.
(In reply to Jan Honza Odvarko from comment #41)
> As I already mentioned in bug 935203 comment 66 the problem is not to
> distinguish a dynamic script (now when we have the introductionType) and so
> generate unique URLs on the client side is simple. The real problem is
> that the debugger does *not* know about these unique client side URLs and
> continues using its own broken versions. This means that: all stack frames
> sent back to the client are still wrong and dealing with breakpoints
> (breakpoints also depend on URL) is a lot harder. Btw. in case of unique
> script URLs, it would be a lot easier to reuse the existing BreakpointActor.

So, if the debugger server provided URLs like those produced by bug 935203 comment 60, perhaps as an additional property on source location forms, would that address this concern?

If so, could you file a bug? I can implement that immediately.
(In reply to Dave Camp (:dcamp) from comment #42)
> Adding drag to the spidermonkey for the entire ESR31 cycle is a pretty big
> pain.  We need to consider the possibility of having a
> nightly/aurora/maybe-even-beta cycle which is incompatible with Firebug if
> it means our engine developers can move faster.

Could we ship JSD1 in Firefox 31 but remove it from ESR 31? Do we have telemetry on how many ESR users have Firebug installed?
(In reply to Dave Camp (:dcamp) from comment #42)
> Honza, how early can the jsd2-based firebug be released?
We are now hardworking mostly on our automated test suite now
and my estimate is: in weeks. I believe we could have 
first Firebug 2.0 alpha 1 out at the first week in April.

Main biggest concern is that the introductionType is not working in some cases.

> So, if the debugger server provided URLs like those produced by bug 935203 comment 60,
> perhaps as an additional property on source location forms
I believe that the best way (for both, the platform and any extension like Firebug) would
be what is mentioned in bug 935203 comment 66 - have a way how to convince the debugger to use given URLs. This way extension can compute unique URL for a source object (the implementation can be tricky for e.g. inline event handlers), set it into the script object and the debugger would use such URL in all stack traces that are sent back to the client. 

However, I don't believe we can finish this (or any similar solution) in the Firefox 30 timeframe. Note that Fx 31 merge is 2014-03-17, so we have just one week.

The think I am mostly worried about at this moment is that the introductionType doesn't work in all cases and this should definitely be fixed this week, so it's part of Firefox 30. Firebug needs this to come up with workarounds. See my last 3 comments in bug 935203 comment 70 (70, 71, 72).
Please Jim, this is where you can help the most!

Honza
I'm going to assume that the problems Honza has with introductionType are fixed in 31.

If we remove JSD1 in Firefox 31, you will need to run an alpha Firebug with Firefox 31+ until Firebug 2.0 is final.  Firebug would then have 19 weeks from now to go final if it wanted to support Firefox 31 stable with a stable firebug.

I think asking folks to run the alpha/beta if they're on prerelease Firefox is a reasonable tradeoff to save the Spidermonkey hackers from a year of increased drag implementing new things and backporting security fixes.

If there's any chance of Firebug 2.0 making stable in the next 19 weeks, I think we should feel ok rm'ing jsd.
The previous comment does assume a drag caused by backporting.  If spidermonkey folks don't think the intersection of "things to be backported" and "things that are complicated by jsd" is that high, that changes the math.
(In reply to Jan Honza Odvarko from comment #46)
> The think I am mostly worried about at this moment is that the
> introductionType doesn't work in all cases and this should definitely be
> fixed this week, so it's part of Firefox 30. Firebug needs this to come up
> with workarounds. See my last 3 comments in bug 935203 comment 70 (70, 71,
> 72).
> Please Jim, this is where you can help the most!

Yes, I'm working on exactly that.
(In reply to Jim Blandy :jimb from comment #49)
> (In reply to Jan Honza Odvarko from comment #46)
> Yes, I'm working on exactly that.
Ok, I believe it's happening in bug 978657

Honza
(In reply to Dave Camp (:dcamp) from comment #48)
> The previous comment does assume a drag caused by backporting.  If
> spidermonkey folks don't think the intersection of "things to be backported"
> and "things that are complicated by jsd" is that high, that changes the math.

It's more on the XPConnect side TBH. Though the potential removal of JSContexts is going to cross swords with JSD, which uses JSContexts exclusively.

It wouldn't be the end of the world if we couldn't remove JSD before esr31. But if we can make it happen without inflicting major pain, we should. It also provides a nice motivation to tie off this project, which has been plodding along for a long time now.
This is the JSD deprecation warning, landing on Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/9550ceef07ff
The Aurora tree rules say one should set "status-FirefoxN: fixed" when one lands patches on Aurora, but since the deprecation warning patch isn't a fix for this bug, I've left that unset.
THANK YOU, BUGZILLA
Attached patch Remove the js/jsd directory. (obsolete) — Splinter Review
It's not happening yet; Honza just wanted a build with a deleted JSD he could use for experimentation.

https://tbpl.mozilla.org/?tree=Try&rev=23aba5cdd49d
(In reply to Jim Blandy :jimb from comment #58)
> It's not happening yet; Honza just wanted a build with a deleted JSD he
> could use for experimentation.
Thanks Jim!

> https://tbpl.mozilla.org/?tree=Try&rev=23aba5cdd49d
Can you please check also Win7 platform? (just for the next time)

Honza
Assuming you still want this for the next ESR, requesting tracking.
jimb: what is your current plan for removing JSD? You landed the JSD deprecation warning in Aurora 29, which is now Firefox 29. Did you want to remove JSD before or after ESR 31 (now Aurora)?
Flags: needinfo?(jimb)
(In reply to Jim Blandy :jimb from comment #55)
> Created attachment 8393956 [details] [diff] [review]
> Delete all references to the obsolete Venkman chrome debugger from the tree.

AFAIK, Venkman is still shipped as part of SeaMonkey nightlies. If Venkman is to be killed, I suppose something else will have to be found, and shipped in its stead.
(In reply to Tony Mechelynck [:tonymec] from comment #62)
> (In reply to Jim Blandy :jimb from comment #55)
> > Created attachment 8393956 [details] [diff] [review]
> > Delete all references to the obsolete Venkman chrome debugger from the tree.
> 
> AFAIK, Venkman is still shipped as part of SeaMonkey nightlies. If Venkman
> is to be killed, I suppose something else will have to be found, and shipped
> in its stead.

Venkman is already zombie-ing along. Very little of it still works at all. I don't think this concern should stop us from removing JSD1 (and officially declaring Venkman dead).

As far as I know, Philipp Kewisch (Fallen)  did some work on making the new devtools (and specifically the debugger) work with Thunderbird and Seamonkey. That should be used instead of Venkman. I would imagine that large parts of the debugger already ship with seamonkey, as a lot of it lives in toolkit. I don't know if this includes the UI, or how SM would like to go about doing that inclusion, but this is really a matter of a different bug.
As far as I've heard and tested, Seamonkey works fine with the devtools server. I believe there is also integrated support for it, but the devtools server extension that can be built in mail/components/devtools works fine with it too. We might want to move that to mailnews/ but its indeed a different bug. This is not an official Seamonkey decision, but it looks like some Seamonkey folks are on CC and can handle that as they wish.
We were just discussing this in our Tuesdays meeting. We are OK with removing Venkman references from the tree and using the remote debugger in Firefox to debug SeaMonkey Chrome.
It would be nice if it could land in the aurora cycle (about 3 weeks left)
Since we're into the second half of this cycle, it'd probably be better to #ifdef JSD for 31 and add a compile flag for enabling JSD, then scream[1] at anyone enabling this. The reason is that there may be developers expecting the next ESR to have JSD (since it migrated to Aurora) and they may not be able to react in time for the ESR release. With the flag, they gain a little bit of extra time (not necessarily until the next ESR) if they really need to use the old API. Also, this should be less risky to uplift (given how far we're in the cycle) and allow for easier response to unforeseen incidences. 


[1] e.g. "JSD is no longer maintained and will be fully removed in the next version. Use X instead."
My understanding is that the argument for removing JSD1 from ESR is that its presence makes code maintenance extremely difficult, and would prevent patches from being easily backported. I don't see how hiding it behind a compile-time flag would help that situation any, unless we're willing to completely break it whenever it becomes inconvenient.

If we're going to leave the code in place, I think we should leave it enabled in production builds. If we're not going to leave it enabled in production builds, I think we should remove it entirely.
If it is a feature we don't want to maintain any more, in the context of ESR, I would prefer Florian's solution (#ifdef) as a temporary solution (the next step would be to remove the code, maybe for 32 or 33).
Jim, if that is ok with you, could you implement such change?
I think now would be a good time to remove JSD. We are after an ESR and Fireburg 2.0 was just released.
We are not going to remove JSD in Beta 31, so we don't need to track this bug for Firefox 31.

jimb: is Nightly 32 a good time to remove JSD? As evilpie points out in comment 70, ESR (32) has left the station for Aurora.
Flags: needinfo?(jimb)
Yes, can we remove JSD now?

For the string work I'm doing (bug 998392), I'll need to fix some API calls in JSD. It won't take a lot of time if I really have to, but if we could just remove this code that would be best...
Flags: needinfo?(jimb)
Yes, it sounds like this is the release to remove it. Can someone write a patch?
I've got a preliminary patch attached to this bug. I'll finish it off.
Flags: needinfo?(jimb)
Comment on attachment 8393956 [details] [diff] [review]
Delete all references to the obsolete Venkman chrome debugger from the tree.

Preparation for deleting JSD.
Attachment #8393956 - Flags: review?(ted)
Blocks: 1019892
Freshened and improved.
Freshened and improved.
Attachment #8393957 - Attachment is obsolete: true
Attachment #8393958 - Attachment is obsolete: true
Attachment #8444768 - Flags: review?(bobbyholley)
Attachment #8444768 - Flags: review?(ted)
Attachment #8444768 - Flags: review?(bugs)
Attachment #8444769 - Flags: review?(jorendorff)
Attachment #8444768 - Flags: review?(bugs) → review+
Comment on attachment 8444768 [details] [diff] [review]
Remove references to JSD from outside js/jsd.

Review of attachment 8444768 [details] [diff] [review]:
-----------------------------------------------------------------

\o/
Attachment #8444768 - Flags: review?(bobbyholley) → review+
diffstat on the last patch:

 40 files changed, 14946 deletions(-)
Attachment #8393956 - Flags: review?(ted) → review+
Comment on attachment 8444768 [details] [diff] [review]
Remove references to JSD from outside js/jsd.

Review of attachment 8444768 [details] [diff] [review]:
-----------------------------------------------------------------

Neat!
Attachment #8444768 - Flags: review?(ted) → review+
If you could remove the lines
34 # Bug 800200 - JSD1 is leaking, but it is about to be removed, so ignore it. m4
35 leak:jsd_CreateLock
36 leak:jsdScript::GetExecutableLines
37 leak:jsdService::ActivateDebugger
from build/suppressions/lsan_suppressions.txt at the same time I'd appreciate it.  r=me.
Comment on attachment 8393956 [details] [diff] [review]
Delete all references to the obsolete Venkman chrome debugger from the tree.

>- * command-line-handler c-extensions   @mozilla.org/extension-manager/clh;1
>+  * command-line-handler c-extensions   @mozilla.org/extension-manager/clh;1
(Extraneous space crept in here.)
See Also: → 1029513
Comment on attachment 8444769 [details] [diff] [review]
Remove the js/jsd directory.

Review of attachment 8444769 [details] [diff] [review]:
-----------------------------------------------------------------

r++++++++
Attachment #8444769 - Flags: review?(jorendorff) → review+
BTW, I strongly suggest you touch CLOBBER when you push this as our build system often doesn't cope well with file deletions.
Comment on attachment 8444769 [details] [diff] [review]
Remove the js/jsd directory.

Review of attachment 8444769 [details] [diff] [review]:
-----------------------------------------------------------------

\o/
Attachment #8444769 - Flags: review+
(In reply to Andrew McCreight [:mccr8] from comment #82)
> If you could remove the lines
> 34 # Bug 800200 - JSD1 is leaking, but it is about to be removed, so ignore
> it. m4
> 35 leak:jsd_CreateLock
> 36 leak:jsdScript::GetExecutableLines
> 37 leak:jsdService::ActivateDebugger
> from build/suppressions/lsan_suppressions.txt at the same time I'd
> appreciate it.  r=me.

Okay, I've made this change.
(In reply to neil@parkwaycc.co.uk from comment #83)
> >- * command-line-handler c-extensions   @mozilla.org/extension-manager/clh;1
> >+  * command-line-handler c-extensions   @mozilla.org/extension-manager/clh;1
> (Extraneous space crept in here.)

This is fixed in the current version of the patch.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #85)
> BTW, I strongly suggest you touch CLOBBER when you push this as our build
> system often doesn't cope well with file deletions.

Okay. Thanks for the advice!
relnote-firefox: --- → ?
\o/ \o/ \o/

Any bugs or plans to take a hatchet to js/public/OldDebugAPI.h?  It seems whatever is left of it would go into some other public header or jsfriendapi.h.
(In reply to Luke Wagner [:luke] from comment #92)
> \o/ \o/ \o/
> 
> Any bugs or plans to take a hatchet to js/public/OldDebugAPI.h?  It seems
> whatever is left of it would go into some other public header or
> jsfriendapi.h.

Yes, there's a bunch of stuff that's now unreferenced. I left that for a follow-up patch.
Blocks: 1029513
What remains to be done here, considering this was leave/left-open?
Forgot to remove that. This can be closed.
Whiteboard: [firebug-p1][leave open] → [firebug-p1]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Jim Blandy :jimb from comment #93)
> (In reply to Luke Wagner [:luke] from comment #92)
> > \o/ \o/ \o/
> > 
> > Any bugs or plans to take a hatchet to js/public/OldDebugAPI.h?  It seems
> > whatever is left of it would go into some other public header or
> > jsfriendapi.h.
> 
> Yes, there's a bunch of stuff that's now unreferenced. I left that for a
> follow-up patch.

Is there a bug on file for that, yet?
Blocks: 1031876
Blocks: 1031878
Blocks: 1031880
Blocks: 1031881
(In reply to Florian Bender from comment #96)
> Is there a bug on file for that, yet?

I just filed a few, one with a patch. I'm sure there's more to be found combing through js/public/OldDebugAPI.h.
Thanks a lot!
You didn't change the b2g and mobile/android package manifest.
(In reply to Mike Hommey [:glandium] from comment #99)
> You didn't change the b2g and mobile/android package manifest.

I don't even know what that is. If you give me a pointer, I'll try to take care of it.
Are you referring to the reference to @BINPATH@/components/jsdebugger.xpt in b2g/installer/package-manifest.in, mobile/android/installer/package-manifest.in, and browser/installer/package-manifest.in? That's referring to js/ductwork/debugger/JSDebugger.cpp, which is not what was deleted. That's just the stub that fronts JS_DefineDebuggerObject to chrome; that's the new Debugger.
Oh! You must mean this.

I didn't even know this existed. I tried grepping for everything I could think of, and then hoped Try would find the rest. (Why didn't this cause build failures on Try?)
Attachment #8447861 - Flags: review?(mh+mozilla)
Are we planning to backport this to Aurora32 as well or let it ride the 33 train?
Blocks: 1032317
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #103)
> Are we planning to backport this to Aurora32 as well or let it ride the 33
> train?

I have no opinion, but it's not a hard patch to backport.
I think that can ride the train. We missed the ESR (31). I think there is no emergency now.
Comment on attachment 8447861 [details] [diff] [review]
Remove jsdservice.xpt from package manifests.

Review of attachment 8447861 [details] [diff] [review]:
-----------------------------------------------------------------

Sadly, android and b2g builds ignore errors in package-manifest.
Attachment #8447861 - Flags: review?(mh+mozilla) → review+
Depends on: 1040122
Release notes updated with the wording:

"JSD (JavaScript Debugger Service) removed in favor of the Debugger interface (lean more)"

Lean more point to https://developer.mozilla.org/en-US/docs/Tools/Debugger-API
s/lean/learn/
thanks Benjamin
Keywords: dev-doc-needed
I reported bug 1040122 about the documentation.
Blocks: 1042038
Blocks: 1043577
Blocks: 1043578
Blocks: 1043588
@sledru The link for the release note[1] is missing a colon, so it's broken. Can you fix that?

Sebastian

[1] https://www.mozilla.org/en-US/firefox/33.0a2/auroranotes/
Right, fixed. Thanks.
Please wait for 30 minutes to see the new page (cache).
That was quick! The fix is already online. Thanks.

Sebastian
Blocks: 1045584
Blocks: 1063296
Blocks: 1060936
Blocks: 1056411
You need to log in before you can comment on or make changes to this bug.