- MobileFrontend uses mw.user.sessionID, which essentially persists across all pageviews in the same tab (see T118063#4547350 for more details).
- The visual editor uses mw.user.generateRandomSessionId().
- The 2010 wikitext editor uses MWCryptRand::generateHex(32).
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | nshahquinn-wmf | T202132 EPIC: Generate one-off metric snapshots for mobile editing documentation | |||
| Resolved | nshahquinn-wmf | T202147 Snapshot: which parts of the edit process cause people to abort edits? | |||
| Resolved | nshahquinn-wmf | T202437 Identify and fix data quality problems in the Edit event log | |||
| Declined | None | T203620 Implementations of the Edit schema generate session IDs differently |
Event Timeline
Comment Actions
I think you might be wrong about MobileFrontend using the persistent sessionId. Far as I can tell, it generates a new one via mw.user.generateRandomSessionId() for all the editor event logging every time the editor route is reached. (See: MinervaNeue's definition of the editor options in skins.minerva.editor/init.js.)
WikiEditor's approach seems harmless. It's a unique code per-pageview, like the other two.
Is anything here causing a problem?
(Obviously, there's a future problem if you want the usage stuff we're logging for T202656 to use the same editing session ID as mobile. But that's surmountable, and not yet part of the requirements. 😜)
Comment Actions
Yeah, you're right. I was confusing the session token they use for their own schemas with the separate one they generate for the Edit schema.
So there's no bug here. I think we will want to revisit how we identify sessions in the future, but now there's not much urgency.