1528219 - [remote-dbg-next] Backward compatibility issues for Firefox 67

Status: RESOLVED FIXED

(DevTools :: about:debugging, enhancement, P3)

Description

[Julian Descottes [:jdescottes]]

I am logging this to start collecting the backward compatibility issues we will have with Firefox 67 when connecting to older versions.

We know the Debugger already broke backward compatibility (Bug 1528168). Depending on what other non-backward compatible changes we have scheduled for Fx67, we should display appropriate messages to users who try to connect from 67 to any older version.

Comment 1

[Julian Descottes [:jdescottes]]

Attachment: Bug 1528219 - Display explicit non-backward message when trying to connect from 67 to older version

Comment 2

[Julian Descottes [:jdescottes]]

Here's an example of a message we could show, dedicated to a single backward compat issue.

Comment 3

[Julian Descottes [:jdescottes]]

Attachment: message_example_webide.png

Comment 4

[Julian Descottes [:jdescottes]]

Just discussed with Alex and Yulia, there won't be non-backward changes related to Fission in 67. Jason, is there any other non-backward compatible change planned for the debugger in Fx67 (ie the next 4 weeks) ?

Comment 5

[Patrick Brosset <:pbro>]

It would be great to know how likely people are to experience this non backward-compatible change (and others like it in the future).
I wonder how much telemetry we have on this. I guess not a lot, if any at all.

We should probably start here, and add a probe that tracks when people attempt to connect to remote targets and what versions both the toolbox and target were.

For more context, this was initially discussed with digitarald, jlast and apoirot. The conclusion was that non-backward compatible changes are inevitable. Especially with a project like Fission coming up.

It'd be great to group non-backward compat changes together, to minimize impact on users.
However the 2 breaking changes we're considering now (the current debugger one, and fission) are most probably not going to happen in the same release.

I think we need an agreed-upon process for when it's fine to break compat, and when it's not. And adjust the messaging displayed in about:debugging/webide to tell users to either install a more recent version on the target, or use an older toolbox.

Comment 6

[Julian Descottes [:jdescottes]]

We have less than a month before the end of 67 cycle. I think Patrick's proposal here is good. We can add probes focused on the version compatibility when we establish a connection. The probes will have to be both in WebIDE and about:debugging.

On top of that I can add the message proposed in the patch here. Harald, would you prefer to remove the suggestion to use another Fx version from the text? Current text is "The connected runtime is not compatible with using breakpoints in the Debugger. Please use Firefox Desktop %1$S if you need to set breakpoints.". Any suggestions?

Comment 7

[Jason Laster [:jlast]]

So, we've already made several backward incompatible changes to how breakpoints are set and managed.

Wednesday, we changed the default worker debugging mode to "windowless" where we use a single toolbox to connect to all the threads. I believe we will drop the old approach, which will be a breaking change for worker debugging.

Comment 8

[Julian Descottes [:jdescottes]]

On the latest Nightly, the Debugger is completely blank when connecting to older runtimes.

Update: This issue seems to be a mix between the changes around newSource events and the recent worker refactors.

Comment 9

[Julian Descottes [:jdescottes]]

I don't know if we will have a fix for the blank debugger issue described in bug 1530861, let's assume the backward compatibility is completely broken for the debugger here.

We should use a message such as: "The Debugger panel may not work with the connected runtime. Please use Firefox Desktop %1$S if you need to use the Debugger on this runtime." Anyway I will start writing patches, anybody is welcome to suggest a better message at any point :)

I will be on PTO starting next monday so here are my next steps for this bug:

• [ ] cleanup patch with updated backward compatibility message
• [ ] file follow up to add probes in WebIDE and events in about:debugging to know which backward compatibility issues users are facing

Logan: may I ask you to keep an eye on this bug? In case the discussion about what the message should say to users is still ongoing when I go on PTO, it would be great to have someone from the debugger team involved and ready to pickup the remaining work. The patch will involve tiny changes in WebIDE and about:debugging, but I can walk you through these anytime this week.

Comment 10

[Julian Descottes [:jdescottes]]

Removing from remote debugging, not really related to this project.

Comment 11

[Logan Smyth [:loganfsmyth]]

Sure, I'll keep an eye on things.

Comment 12

[Julian Descottes [:jdescottes]]

Regarding probes in WebIDE, we already have histograms logging the Runtime information after each successful connection. This should be enough. We will add the missing info to aboutdebugging in Bug 1530997, but no need to block this bug on it.

Comment 13

[Julian Descottes [:jdescottes]]

Some info about the current backwards compatibility usage (histogram DEVTOOLS_WEBIDE_CONNECTED_RUNTIME_VERSION)

For DevEdition 66

Server version	N -> ?	Connections	%
Fx 62	N -> N-4	4	0.5
Fx 63	N -> N-3	22	2.5
Fx 64	N -> N-2	161	18.7
Fx 65	N -> N-1	500	57.7
Fx 66	N -> N	118	13.6
Fx 67	N -> N+1	62	7.2
Total		867	100

For Nightly 67

Server version	N -> ?	Connections	%
Fx 64	N -> N-3	2	0.2
Fx 65	N -> N-2	43	5.1
Fx 66	N -> N-1	123	14.6
Fx 67	N -> N	676	80.1
Total		844	100

Comment 14

[Julian Descottes [:jdescottes]]

I will not be able to land this patch now since I will be on PTO in a few hours. And I won't be back before the end of 67, so if this needs to land feel free to take over the patch, amend it and land. I am unassigning myself from this Bug in the meantime.

Since Alex fixed Bug 1530861, the current status when remote debugging Fx 67 -> Fx 65 or 66 is that only breakpoints are not working.
You have current telemetry figures for remote debugging attempts in the comment above. As a reminder they don't account for the total usage of remote debugging, but you can compare them with usage metrics for devtools panels to get an idea of the severity.

The current message in the patch is The Debugger panel may not work with the connected runtime. Please use Firefox { $runtimeVersion } if you need to use the Debugger with this runtime.

In my opinion, since the UI is not completely broken at the moment, and the usage numbers are relatively low, I don't think landing this is a must. But it would be nice to have input from Harald here.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3e43e15218d9
Display explicit non-backward message when trying to connect from 67 to older version r=daisuke,loganfsmyth

Comment 16

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/3e43e15218d9