1105493 - Compatibility after Debugger.Source Integration

Status: RESOLVED WONTFIX

(DevTools :: Debugger, defect, P2)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Debugger compatibility has changed after the patches in bug 905700.

If you try to use a client that does not have these patches (old client) with a server that does (new server), then breakpoints will no longer be hit anymore.

This is not one of the cases called out directly on the compatibility page[1], as it's usually the case that a new server feature *requires* an equal or newer client before the feature can be used, as the client does not make the new RPC call, show the UI, etc.

But, that's not the case here.  The debugger UI looks like it will work fine with a newer server with these patches but fails to.  This suggests to me that the upgraded server no longer supports that APIs that an older client expects.

In my limited testing locally, nothing is sent over the RPC at all when setting a breakpoint in this old client w/ new server setup.

James & Nick: Is there a fix we could pursue here?  It would be wonderful to keep the debugger working in this case if we can.

If you are wondering how this would come up in the real world, here are some examples:

* Using Dev. Edition today to debug Fennec Nightly
* Using Dev. Edition today to debug future B2G simulator releases

[1]: https://wiki.mozilla.org/DevTools/Backwards_Compatibility

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to J. Ryan Stinnett [:jryans] from comment #0)
> it's usually the case that a new server feature *requires* an
> equal or newer client before the feature can be used

This was what we designed for. APIs changed and unless we want to uplift changes to old clients, they won't be able to handle them, but at that point we might as well uplift the whole D.S patches.

I don't think there is anything to do here.

Comment 2

[James Long (:jlongster)]

Agreed, we assume that the client is the same version or higher. There's really not a good way to get it to work the other way around.

It's a good point though, and I wonder if there's any way we should be communicating this kind of thing to the user. Maybe even an explicit check when a client connects to the server. If the server is newer, we could show a warning. For now I think we should close this bug though.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I am now seeing the problem in Firebug 2 (one of the old clients) - breakpoints don't work.
Reported here: https://code.google.com/p/fbug/issues/detail?id=7724

What exactly has changed (from a client perspective) and how should I fix it?

Honza

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

James, any tips?

Comment 5

[James Long (:jlongster)]

(In reply to Jan Honza Odvarko [:Honza] from comment #4)
> James, any tips?

As mentioned above, we can't realistically support old client -> newer server connections, but it's not hard to fix this if you can publish a patch version of an older client.

You basically just need to call `setBreakpoint` on the `SourceActor` in instead of the thread. I'm not too familiar with Firebug, do you use the RDP? Looking at that stack trace makes me think you're not. You need to get a `SourceActor` (you should already have this if you're viewing source/setting bps) and just call `setBreakpoint` on it with the same parameters.

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I recommend using the DebuggerClient instead of your own home rolled thing, as everything should then just work.

If that's not an option, you have to send breakpoint requests to the SourceActor, as James mentioned.

James, did you update the RDP docs? Send a PR to https://github.com/jimblandy/DebuggerDocs if not.