[00:01:06] because it's really the metadata requirement that is most of the problem [00:03:24] I'll start looking into implementation detail. what are the API differences we need to do then gwicke? [00:04:22] Krenair: data-mw will be exposed basically the same way data-parsoid is exposed right now [00:05:47] if you'd like to kick off both requests at once, then you could request both by title only [00:06:01] by title only? [00:06:31] IIRC you don't know the latest revision at that point, so you are requesting /html/{title} [00:06:53] data-mw will basically work the same way [00:07:35] to make sure that data-mw matches the html render, the etag headers should be compared [00:09:29] We sometimes set an oldid as well [00:09:45] in the rare case that they don't match, the data-mw request should be repeated using the revision and etag returned by the html response [00:10:13] passing in the oldid is fine, just make sure to pass it in both html & data-mw requests [00:10:40] * Krenair nods [00:11:24] https://meta.wikimedia.org/api/rest_v1/?doc shows data-parsoid and html among other things [00:11:25] but no data-mw? [00:11:31] eventually, I hope that we can relax the requirement for tids to match [00:11:40] that'll require stable ids in parsoid, though [00:11:59] Krenair: yeah, data-mw is not available yet [00:12:32] I'm actually not entirely sure what the timeline on the parsoid end is at this point [00:13:24] they are working on it, but it's still at least weeks out [00:15:55] Krenair: in any case, we will continue to support old-style requests for quite a while, as long as the expected content-type is specified in the `Accept` header [00:16:23] so VE won't break even if the move to data-mw usage is a bit delayed [00:16:58] okay, I think we should look into this after restbase supports it [00:17:35] yeah, or at least when we are getting ready to deploy [00:18:05] okay, when it's on restbase master? :p [00:19:00] Krenair: Talking to RoanKattouw we fundamentally rely on data-mw synchronously for every cite, every template, and a bit for images. [00:19:16] yeah [00:19:28] so we can't delay loading of it, it has to be one of the blockers for loading [00:19:47] James_F: for *rendering*? [00:19:52] gwicke: Yes. [00:19:58] For *understanding the HTML* [00:20:00] hm, strange [00:20:17] which information from data-mw do you need for rendering? [00:20:30] For edits: https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/25be46a57d6b875b64fb3455c93fa776d6d301ee/modules/ve-mw/dm/nodes/ve.dm.MWExtensionNode.js for every extension. [00:21:24] that just stashes it away it seems? [00:21:41] For read: https://github.com/wikimedia/mediawiki-extensions-Cite/blob/07db923b86e9a97c7c05be8b22f67df96add1ad9/modules/ve-cite/ve.dm.MWReferenceNode.js for references (so we know which reference is a re-use), https://github.com/wikimedia/mediawiki-extensions-Cite/blob/07db923b86e9a97c7c05be8b22f67df96add1ad9/modules/ve-cite/ve.dm.MWReferencesListNode.js for [00:21:41] reference lists (so we know which group of references with which to populate it), and https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/25be46a57d6b875b64fb3455c93fa776d6d301ee/modules/ve-mw/dm/nodes/ve.dm.MWTransclusionNode.js for the name of the template (so we can match the cite templates). [00:21:51] Yeah, hence, 'for edits'. [00:22:09] The killer use-cases on reads are all related to Cite. Shock, surprise. [00:23:06] when you say 'read', do you mean that this shows up in the initial VE render? [00:23:22] or that the information is needed once the user clicks on a citation? [00:24:05] Initial VE render. [00:25:06] * gwicke never noticed any such information [00:25:22] James_F: is this triggering some icon, or something? [00:26:18] The ordering and numbering of the references. The contents of the reference lists. [00:26:19] Et. [00:26:44] ah, it is because VE re-builds references from scratch, rather than using Parsoid's render? [00:36:59] Yes [00:37:10] And because Parsoid doesn't provide that information itself [00:37:31] At least not enough of it [00:41:31] that certainly sounds like it would be harder to change [00:55:16] 10VisualEditor, 10VisualEditor-MediaWiki: Single Edit Tab "four choices" dialog doesn't go away when you exit the visual editor - https://phabricator.wikimedia.org/T130552#2143249 (10AlexMonk-WMF) VE captures the escape key press when you have the document focused, the SET dialog captures it if you have the di... [00:56:10] 10VisualEditor, 10VisualEditor-MediaWiki: Single Edit Tab "four choices" dialog doesn't go away when you exit the visual editor - https://phabricator.wikimedia.org/T130552#2143251 (10AlexMonk-WMF) (It seems that we try, it's just that the edit surface finishes loading *afterwards*, stealing focus again) [01:09:16] (03PS1) 10Alex Monk: Don't change focus to VE surface if we're opening the SET dialog [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/279081 (https://phabricator.wikimedia.org/T130552) [01:58:19] (03CR) 10Alex Monk: "Anyone else have any thoughts?" [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/263655 (https://phabricator.wikimedia.org/T53375) (owner: 10Alex Monk) [02:04:06] 10VisualEditor, 10VisualEditor-MediaWiki: Fix "1 notice" on the remaining wikis - https://phabricator.wikimedia.org/T103693#2143333 (10AlexMonk-WMF) I attempted to apply @Krinkle's edits on metawiki (but they didn't seem to fix the issue, at least on the page that I tested) and enwikibooks (but my template edi... [04:09:06] Krenair: Looking at metawiki now [04:09:27] Using action=edit source mode, I see
[04:09:27]