Page MenuHomePhabricator

2010 wikitext editor does not emit init events
Closed, DuplicatePublic

Description

According to @DLynch:

init isn't logged at all in WikiEditor. We could add the call into ext.wikiEditor.js or maybe ext.wikiEditor.toolbar.js and have it with a similar-ish meaning to the event in VisualEditor. That said, it might not be a close enough equivalent -- the VE call to it is for "something has happened which is causing us to start working on loading the VE js", and WikiEditor doesn't have quite the same model -- it's entirely "oh, you opened the page? Okay, editor's loading." Given which, you might just want to use the load time from the loaded/ready events instead, I think? @Esanders might remember better whether we deliberately left that out.

According to @Jdforrester-WMF:

Yup [this was deliberately left out]. This is because sessions launched by non-JS users won't trigger any JS-land activity (just server-side activity).

Event Timeline

nshahquinn-wmf created this task.

I’m not clear on whether we should be changing this?

nshahquinn-wmf moved this task from Triage to Tracking on the Product-Analytics board.

I’m not clear on whether we should be changing this?

Hmm. I was thinking we definitely needed the init to calculate the edit save rate, which is now our primary program metric. However, it actually looks like we defined this in the past as the number of saveSuccess events over the number of ready events.

But what about the editing performance measurements that we did earlier this year? Both metrics there are defined to start from "the user clicking an "Edit" or "Edit source" button", so I don't know how we calculated that for the 2010 wikitext editor if we don't log init. @Deskana, do you know? I don't see any queries linked from the report.

@DLynch, @Jdforrester-WMF are you sure init has never been logged? This bit in WikiEditorHooks.php really looks like it's doing just that.

I talked about this more with @Jdforrester-WMF, and he pointed out that logging the init event on the server side isn't directly comparable to the visual editor's init. The server side event would come as the server is producing the edit page to send to the client, which will be some time after the user originally clicks the edit button to request that page. The visual editor actually logs the init when the user first clicks the edit button, which it can do because, unlike the 2010 wikitext editor, the editor load does not involve the page reload. Making this fully comparable would probably involve using an editing session ID persisted in session storage and regenerated whenever a new edit is initiated.

He also answered my question about the editing performance report: each ready event contains a readytiming property which is computed by the client, so it's not necessary to compare multiple events on the analysis side to measure performance. Assuming both the visual editor and the 2010 wikitext editor use the Navigation Timing API, the measurements should be comparable.

So yeah, I don't see a strong argument that this needs to be implemented, but we should still figure out why based on the code it seems to already be implemented and consider whether to fix that or strip it out.