Closed Bug 1528219 Opened 6 months ago Closed 6 months ago

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

Categories

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

enhancement

Tracking

(firefox67 fixed)

RESOLVED FIXED
Firefox 67
Tracking Status
firefox67 --- fixed

People

(Reporter: jdescottes, Assigned: jdescottes)

References

Details

(Keywords: dev-doc-needed)

Attachments

(2 files)

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.

See Also: → 1528168

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

Priority: -- → P3

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) ?

Flags: needinfo?(jlaster)
See Also: → 1528766

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.

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?

Flags: needinfo?(hkirschner)

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.

Flags: needinfo?(jlaster)

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.

See Also: → 1530861

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.

Flags: needinfo?(lsmyth)
Depends on: 1530997

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

No longer blocks: remote-debugging-ng-m2
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED

Sure, I'll keep an eye on things.

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.

No longer depends on: 1530997

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

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.

Assignee: jdescottes → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(hkirschner)
Keywords: dev-doc-needed
Pushed by lsmyth@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Assignee: nobody → jdescottes
Flags: needinfo?(lsmyth)
Duplicate of this bug: 1528168
You need to log in before you can comment on or make changes to this bug.