Closed Bug 1054493 Opened 5 years ago Closed 5 years ago

[e10s] Make docshell charset/character set telemetry work


(Firefox :: General, defect)

Not set



Tracking Status
e10s + ---


(Reporter: adw, Assigned: jimm)



Bug 999293 made Firefox's charset menu work in e10s, but it copied docShell.gatherCharsetMenuTelemetry() from browser.js (now in browser.xml) to browser-child.js:

Telemetry is disabled in child processes, so that line ends up doing nothing, and it should be fixed somehow.  I don't see a reason why this telemetry has to be done in the docshell.  Seems like doing it from the browser chrome JS, where the charset menu code is, would cover the real-word cases where docshells' charsets are changed, although I guess mobile and other apps would need to do the same thing if they wanted the telemetry.

Note that this isn't a regression because before bug 999293 was fixed, the charset menu didn't work in e10s at all.
Depends on: 1024201, old-e10s-m2
Depends on: 1024021
No longer depends on: 1024201
Blocks: old-e10s-m2
No longer depends on: old-e10s-m2
Move old M2's low-priority bugs to M6 milestone.
Assignee: nobody → jmathies
Drew, we have telemetry reporting in the child now (bug 1024021), and I've confirmed that gatherCharsetMenuTelemetry() is getting called in the child in response to an char encoding change in the parent through the text encoding menus.. so I think we can close this out. You mentioned in comment 1 that you had some issues with the way this was put together. Should I morph this into a bug about the location of gatherCharsetMenuTelemetry() or just resolve this wfm?

Either way, I don't think we need to block our milestone 6 on this anymore.
Flags: needinfo?(adw)
Cool, I think my concern in comment 0 is only academic now.
Closed: 5 years ago
Flags: needinfo?(adw)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.