[14:34:50] 10VisualEditor, 10VisualEditor-MediaWiki, 10WikiEditor, 10MediaWiki-Page-editing, and 2 others: Add polytonic characters for Greek to MediaWiki's special character list as used in WikiEditor and VisualEditor - https://phabricator.wikimedia.org/T130535#2140772 (10Jdforrester-WMF) p:5Triage>3Normal a:3E... [14:37:22] 10VisualEditor, 10VisualEditor-MediaWiki, 10WikiEditor, 10MediaWiki-Page-editing, and 2 others: Add polytonic characters for Greek to MediaWiki's special character list as used in WikiEditor and VisualEditor - https://phabricator.wikimedia.org/T130535#2138756 (10Jdforrester-WMF) Hi there. Though doing thi... [14:41:56] (03PS1) 10Jforrester: Update VE core submodule to master (eb97c1f) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278897 [14:43:20] 10VisualEditor, 10VisualEditor-MediaWiki, 10WikiEditor, 10MediaWiki-Page-editing, and 3 others: Add polytonic characters for Greek to MediaWiki's special character list as used in WikiEditor and VisualEditor - https://phabricator.wikimedia.org/T130535#2140815 (10Jdforrester-WMF) [14:51:56] (03CR) 10jenkins-bot: [V: 04-1] Update VE core submodule to master (eb97c1f) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278897 (owner: 10Jforrester) [14:58:57] edsanders: ^^^ Is failing because the tests are wrong in MW, or because we've exposed an issue? [14:59:45] probably needs an update [15:03:31] (03PS1) 10Esanders: SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 [15:06:42] (03CR) 10jenkins-bot: [V: 04-1] SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:06:58] (03PS1) 10Esanders: MWSpecialCharacterDialog: Defer loading of character list [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 [15:07:44] edsanders: I'll fix master. [15:07:59] * edsanders has a look [15:08:03] Ta. [15:11:11] (03PS1) 10Jforrester: Follow-up eb97c1f: Fix build for added language 'inh' [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278905 [15:12:47] (03PS2) 10Esanders: Update VE core submodule to master (eb97c1f) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278897 (owner: 10Jforrester) [15:13:06] Oooh, yeah. [15:13:16] 'We' made a breaking change there. :-) [15:13:18] * James_F is a fool. [15:14:46] edsanders: +2 https://gerrit.wikimedia.org/r/278905 for me? [15:14:56] (03CR) 10Esanders: [C: 032] Follow-up eb97c1f: Fix build for added language 'inh' [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278905 (owner: 10Jforrester) [15:16:57] (03CR) 10Esanders: [C: 031] Update VE core submodule to master (eb97c1f) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278897 (owner: 10Jforrester) [15:24:52] (03Merged) 10jenkins-bot: Follow-up eb97c1f: Fix build for added language 'inh' [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278905 (owner: 10Jforrester) [15:25:23] (03PS2) 10Jforrester: SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:26:48] (03CR) 10Jforrester: [C: 032] "Per Ed." [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278897 (owner: 10Jforrester) [15:28:38] (03CR) 10jenkins-bot: [V: 04-1] SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:30:16] (03CR) 10Jforrester: [C: 04-1] "It don't work, mate." (031 comment) [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:31:28] (03PS3) 10Esanders: SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 [15:33:12] (03CR) 10Esanders: [C: 04-1] SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:33:45] (03CR) 10Jforrester: [C: 04-1] "On first run for me it triggers but the window doesn't show, because (presumably) no content arrives from the promise? Works fine on secon" (031 comment) [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:38:34] (03PS4) 10Esanders: SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 [15:41:52] (03CR) 10Jforrester: [C: 031] "I'd prefer a pending state to the open given in MW it's going to take non-zero number of seconds to execute…" [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:44:45] (03CR) 10Esanders: "It will be pretty close to zero seconds most of the time, but yes, that should be fixed upstream for all toolbar dialogs." [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:45:11] edsanders: Want me to file a ticket? [15:45:18] sure [15:48:40] (03Merged) 10jenkins-bot: Update VE core submodule to master (eb97c1f) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278897 (owner: 10Jforrester) [15:48:49] (03CR) 10Jforrester: [C: 032] "Filed as T130623." [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:50:47] (03PS2) 10Esanders: SpecialCharacterDialog: Defer loading of character list [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 [15:51:48] (03CR) 10Jforrester: SpecialCharacterDialog: Defer loading of character list (031 comment) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 (owner: 10Esanders) [15:54:06] (03Merged) 10jenkins-bot: SpecialCharacterDialog: Use getReadyProcess promise to wait for char list [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/278903 (owner: 10Esanders) [15:57:16] (03CR) 10Esanders: SpecialCharacterDialog: Defer loading of character list (031 comment) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 (owner: 10Esanders) [16:15:50] (03PS3) 10Jforrester: Update VE core submodule to master (d1ce123) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 (owner: 10Esanders) [16:16:06] (03CR) 10Jforrester: [C: 032] "Neat." [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 (owner: 10Esanders) [16:29:36] (03Merged) 10jenkins-bot: Update VE core submodule to master (d1ce123) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 (owner: 10Esanders) [16:42:27] (03CR) 10Esanders: "More like 20k after gzip. I guess it all adds up." [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/278904 (owner: 10Esanders) [17:04:34] 10VisualEditor, 10VisualEditor-Initialisation, 10VisualEditor-Performance, 6Collaboration-Team-Backlog, and 6 others: Store & load data-mw separately - https://phabricator.wikimedia.org/T78676#992164 (10ssastry) [17:04:37] 10VisualEditor, 10VisualEditor-MediaWiki, 10VisualEditor-Performance, 10RESTBase: VisualEditor should load data-mw from a separate API call alongside the body content - https://phabricator.wikimedia.org/T88623#2141404 (10ssastry) [17:05:33] 10VisualEditor, 10VisualEditor-MediaWiki, 10VisualEditor-Performance, 10RESTBase: VisualEditor should load data-mw from a separate API call alongside the body content - https://phabricator.wikimedia.org/T88623#1016326 (10ssastry) [17:06:30] 10VisualEditor, 10VisualEditor-Initialisation, 10VisualEditor-Performance, 6Collaboration-Team-Backlog, and 6 others: Store & load data-mw separately - https://phabricator.wikimedia.org/T78676#2141410 (10ssastry) [17:26:12] 10VisualEditor, 10VisualEditor-MediaWiki, 10WikiEditor, 10MediaWiki-Page-editing, and 3 others: Add polytonic characters for Greek to MediaWiki's special character list as used in WikiEditor and VisualEditor - https://phabricator.wikimedia.org/T130535#2141526 (10Esanders) The additional load time is probab... [17:26:49] 10VisualEditor, 10VisualEditor-MediaWiki, 10VisualEditor-Performance, 10RESTBase: VisualEditor should load data-mw from a separate API call alongside the body content - https://phabricator.wikimedia.org/T88623#2141540 (10ssastry) [17:49:13] (03PS13) 10Divec: Refactor getNodeAndOffset [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/270315 (https://phabricator.wikimedia.org/T124318) [18:06:27] 10VisualEditor, 10VisualEditor-CopyPaste, 6Collaboration-Team-Backlog, 10Flow, and 2 others: Don't strip links when pasting HTML into Flow VisualEditor - https://phabricator.wikimedia.org/T129833#2117358 (10jmatazzoni) @Etonkovidova notes hree small issues(they might be non-issues at all) with copying/past... [18:18:40] 10Cite, 13Patch-For-Review: Allow to preview list-defined references in the section where they are defined - https://phabricator.wikimedia.org/T128036#2141745 (10TheDJ) 5Open>3Resolved [19:03:17] 10Cite, 10Citoid, 10VisualEditor, 10VisualEditor-MediaWiki-References, 13Patch-For-Review: Save references in page_props and cache - https://phabricator.wikimedia.org/T125329#2142030 (10Krinkle) Meeting with @Jdlrobson and @GWicke: * The JavaScript API request must pass along the current page view's rev... [19:04:32] 10VisualEditor, 10VisualEditor-EditingTools: VisualEditor character map not available in dialogs - https://phabricator.wikimedia.org/T128560#2078935 (10Jdforrester-WMF) [19:05:03] 10VisualEditor: After creating a page using VE, left with ugly ?venotify=created appended to URL - https://phabricator.wikimedia.org/T128565#2079046 (10Jdforrester-WMF) Isn't this also set by the wikitext editor? But yes, we should change it. [19:05:23] 10VisualEditor, 10VisualEditor-MediaWiki, 10WikiEditor, 10MediaWiki-Page-editing: After creating a page using VE, left with ugly ?venotify=created appended to URL - https://phabricator.wikimedia.org/T128565#2142044 (10Jdforrester-WMF) p:5Triage>3Low [19:07:40] 10VisualEditor, 10VisualEditor-MediaWiki-References, 10VisualEditor-MediaWiki-Templates: Wrong numbers of references and template boundaries in VisualEditor - https://phabricator.wikimedia.org/T128294#2142079 (10Jdforrester-WMF) [19:07:42] 10VisualEditor, 10VisualEditor-DataModel, 10VisualEditor-MediaWiki-References, 7Epic: In VisualEditor, references in templates cannot be reused and are numbered separately from references in the text. - https://phabricator.wikimedia.org/T52474#558083 (10Jdforrester-WMF) [19:08:33] 10Citoid, 10VisualEditor, 7Design: Provide a way to use Citoid to insert {{cite…}} templates outside a reference, but in a bullet list instead - https://phabricator.wikimedia.org/T128210#2142083 (10Jdforrester-WMF) p:5Triage>3Lowest [19:09:22] 10Citoid, 10VisualEditor, 7Design: Provide a way to use Citoid to insert {{cite…}} templates outside a reference, but in a bullet list instead - https://phabricator.wikimedia.org/T128210#2067449 (10Jdforrester-WMF) This would need quite a lot of thought on how to expose this very rare use case in a way that... [19:09:34] 10Citoid, 10VisualEditor: Support linked RIS file - https://phabricator.wikimedia.org/T128405#2142093 (10Jdforrester-WMF) p:5Triage>3Low [19:10:13] 10VisualEditor, 10VisualEditor-MediaWiki-Links, 10Parsoid: Broken subpage links added in a visual edit - https://phabricator.wikimedia.org/T128384#2142097 (10Jdforrester-WMF) p:5Triage>3Normal [19:10:51] 10Citoid, 10VisualEditor, 10The-Wikipedia-Library: Access to Atekst from Citoid - https://phabricator.wikimedia.org/T128418#2142103 (10Jdforrester-WMF) p:5Triage>3Low [19:12:53] 10VisualEditor, 10VisualEditor-CopyPaste: Copying the (plain) text of citations from a reference template, and pasting that text into a Basic citation form, doesn't work as expected - https://phabricator.wikimedia.org/T123774#2142114 (10Jdforrester-WMF) 5Open>3stalled There is no `References` section in th... [19:13:32] 10VisualEditor, 10VisualEditor-MediaWiki-Templates: Visible template (flagicon) is showing puzzle piece icon - https://phabricator.wikimedia.org/T128391#2142123 (10Jdforrester-WMF) [19:13:34] 10VisualEditor, 10VisualEditor-ContentEditable, 13Patch-For-Review: Template (puzzle) icon displaces images/templates - https://phabricator.wikimedia.org/T127319#2142124 (10Jdforrester-WMF) [19:14:23] 10VisualEditor, 10VisualEditor-ContentEditable: Template (puzzle) icon displaces images/templates - https://phabricator.wikimedia.org/T127319#2039692 (10Jdforrester-WMF) 5Open>3Resolved [19:18:27] 10VisualEditor: Incorrect parsing of nested references within nested templates - https://phabricator.wikimedia.org/T123992#1942689 (10Jdforrester-WMF) This looks like a specialised case of {T52769} and {T52474}, I think? More generally, "nested references" is explicitly not supported edge behaviour in MediaWiki... [19:18:35] 10VisualEditor: Incorrect parsing of nested references within nested templates - https://phabricator.wikimedia.org/T123992#2142151 (10Jdforrester-WMF) [19:18:39] 10VisualEditor, 10VisualEditor-MediaWiki-References, 10Parsoid, 7Epic: Adding a reference in VisualEditor does not update fake references blocks inside templates - https://phabricator.wikimedia.org/T52769#541715 (10Jdforrester-WMF) [19:20:13] 10VisualEditor, 10VisualEditor-Links, 10VisualEditor-MediaWiki-Links, 7Design: Users sometimes struggle to select the text of the link anchor within the cartouche and so delete it on select-retype - https://phabricator.wikimedia.org/T124305#2142159 (10Jdforrester-WMF) p:5Triage>3Normal a:3DLynch [19:22:27] 10VisualEditor, 10VisualEditor-DataModel, 10VisualEditor-MediaWiki-References: Changing a reference's group name somehow deleted the definition of the reference too(?!) - https://phabricator.wikimedia.org/T124439#2142171 (10Jdforrester-WMF) p:5Triage>3High [19:25:01] 10VisualEditor: Editing a reference doesn't display citation details - https://phabricator.wikimedia.org/T124630#2142202 (10Jdforrester-WMF) 5Open>3Invalid Your given example uses `[[en:User:The Thadman/Give Back Our Membership]]` which is almost certainly not what you meant to do; '[[en:' is an (... [19:28:02] 10VisualEditor: Preformatted text and Enter key - https://phabricator.wikimedia.org/T126637#2142237 (10Jdforrester-WMF) [19:28:02] 10VisualEditor, 10VisualEditor-ContentEditable: VisualEditor: Adding newlines at start/end of preformatted text is broken - https://phabricator.wikimedia.org/T60773#2142238 (10Jdforrester-WMF) [19:28:02] 10VisualEditor, 10Graph: [Regression pre-wmf.14] Cannot add a graph in VE , it says "Vega has encountered an error rendering this graph" - https://phabricator.wikimedia.org/T127343#2142241 (10Jdforrester-WMF) 5Open>3Resolved p:5Triage>3Unbreak! a:3Esanders [20:59:03] 10VisualEditor, 10VisualEditor-MediaWiki, 10WikiEditor, 10MediaWiki-Page-editing: After creating a page using VE, left with ugly ?venotify=created appended to URL - https://phabricator.wikimedia.org/T128565#2142525 (10Legoktm) No, the postedit notice used by the wikitext editor uses cookies (mediawiki.acti... [21:26:24] 10Cite: add a special way to add footnotes to a table - https://phabricator.wikimedia.org/T130670#2142614 (10Amire80) [21:26:48] 10Cite: add a special way to add footnotes to a table - https://phabricator.wikimedia.org/T130670#2142626 (10Amire80) [22:01:51] 10VisualEditor: Visual editor Template tool should not show deprecated parameter(s), unless already has value - https://phabricator.wikimedia.org/T130676#2142838 (10Kipod) [22:23:11] James_F, it was https://phabricator.wikimedia.org/T91700 you linked me too earlier, right? [22:40:52] Krenair: Yeah; the VE one is https://phabricator.wikimedia.org/T88623 [22:42:21] and why should we download it separately? [22:43:44] Krenair: Because otherwise we'll be screwed when RESTbase stops shipping it to us. :-D [22:44:00] Why is RESTBase going to stop shipping it to us? [22:44:28] This is all described in Phabricator, but https://phabricator.wikimedia.org/T114279 is the ultimate ticket in the chain right now. [22:46:28] It sounds like this is basically going to be a performance regression [22:47:37] We had this argument with Services two months ago, and lost. So… eh. [22:48:46] They think it won't be slower? [22:54:53] (03PS1) 10Jforrester: Update OOjs UI to v0.16.4 [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/279069 [22:56:18] (03CR) 10Bartosz Dziewoński: [C: 032] Update OOjs UI to v0.16.4 [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/279069 (owner: 10Jforrester) [23:05:55] James_F? [23:06:23] They think that the 0.01% of page views that are edits aren't worth slowing down every reader. [23:07:23] Readers aren't currently getting parsoid HTML [23:07:42] And this is the major blocker as to why. [23:08:16] When readers do get parsoid HTML, presumably we'll actually be able to hugely speed up VE load time? [23:12:23] Yes. [23:13:52] So we should load the full data until then [23:14:05] Yes. [23:14:27] either the full data in one request or just data-mw when we can grab the parsoid HTML from the page [23:14:59] the size should actually be about the same overall [23:15:29] (03Merged) 10jenkins-bot: Update OOjs UI to v0.16.4 [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/279069 (owner: 10Jforrester) [23:15:52] and data-mw can be loaded slightly after html, potentially speeding up time to having a basic editor active [23:17:01] I would also expect a single JSON.parse call to be faster than one per attribute [23:17:13] I'm not seeing the argument to split these into separate requests on VE's side [23:18:20] well, the obvious big win would be to not load HTML that the user already has for viewing, but that's some ways off [23:19:13] re giving bandwidth priority to HTML: is there no way for VE to leverage that for faster loads on slow networks? [23:20:05] Yes, we could have a separate mode where we load parsoid HTML without data-mw from what we already have on the page and download data-mw from the server, that sounds okay [23:21:20] In that situation you wouldn't even request the content itself from the server (maybe just some metadata). But until we get there, I don't see the benefit to us splitting the requests to have most content in one and data-mw in another. [23:21:30] the request* [23:22:25] gwicke: We're almost certainly not going to trust the client-side version of the Parsoid HTML, though. Unless you fill it with SHA1s for us to evaluate and re-fetch if wrong, it won't save anything. [23:22:56] So how is it going to speed up VE load time? [23:24:56] Krenair: as I said, you can load only the HTML, init VE, then load data-mw for template editing [23:25:14] VE can be ready for most editing tasks after only loading the HTML [23:25:15] Is that the only thing we need it for? To open up the template editor? [23:25:37] possibly something about images, too [23:25:40] We don't need it to display the template on the page or anything? [23:26:03] no, the markup to identify content as templated is still inline [23:26:19] gwicke: Except VE is linear right now. [23:26:40] gwicke: Re-writing the client to be non-linear to add data-mw attributes to the model after the fact is… going to be a lot of work. [23:27:10] gwicke: All this change means is that now VE will have to make two HTTP requests to RESTbase (not one), and painfully re-build the HTML we actually want, before doing what we are doing now. [23:27:52] not sure; I think the last time I chatted about this with edsanders he mentioned that it might be possible to take advantage of this without too much trouble; could be wrong on this, though [23:28:14] It's not "trouble" to do an extra HTTP request and re-stitch the HTML, it's just slow. :-) [23:28:33] with 'take advantage', I mean "speed up VE" [23:28:40] Oh. No. [23:29:01] Not unless I've totally mis-understood our architecture. [23:29:18] Which is possible. I'm just the product guy, other people are the engineers. :-) [23:29:20] it depends on how the model can access data-mw info [23:30:08] The Converter uses it on ingestion of Parsoid HTML to create the linear model right now, I believe. [23:30:50] 10VisualEditor, 10VisualEditor-MediaWiki, 10VisualEditor-Performance, 10RESTBase: VisualEditor should load data-mw from a separate API call alongside the body content - https://phabricator.wikimedia.org/T88623#2143087 (10ssastry) [23:31:05] yeah, but looking up some data-mw bit from a hash table given a unique key isn't too hard [23:31:31] once it's initialized, that is [23:31:33] The issue is really in any added overhead [23:31:47] I would expect the main complexity to be in handling the not-yet-initialized case [23:32:11] Yes, that's what I meant about not doing that. :-) [23:32:15] overall cpu overhead might be lower, as there are less JSON.parse calls [23:32:25] Network delay? [23:32:32] time to full HTML will be lower [23:33:08] time to full HTML + data-mw should be about the same [23:34:28] I'm not interested in 'full HTML' on it's own without data-mw on the assumption that VE depends on data-mw to get a basic edit surface displayed (feel free to correct this if you know it to be wrong). [23:34:54] I'm pretty sure that this is wrong in principle [23:36:26] not 100% sure how much work it is to take advantage of this in the short term; data-mw is definitely not needed for rendering, and if there is a way for the model to access shared data, then I don't see how data-mw can't be loaded later [23:36:36] We don't actually rely on it to load the edit surface? Or we shouldn't need to? [23:37:39] the 'not loaded' handling might be as simple as popping up a dialog about standing by until the value is defined [23:38:39] another possible optimization might be to only load data-mw when a template is actually touched [23:39:07] at least under low-bandwidth conditions [23:39:26] I've been doing some grepping and ve.ce.MWExtensionNode.prototype.generateContents does this.getModel().getAttribute( 'mw' ) [23:40:48] okay, and what does it need data-mw for? [23:41:20] it gets body.extsrc and attrs [23:41:46] can I interrupt for a second? I'm confused about something related to this [23:42:05] builds some wikitext out of them, and then... ah, it sends it off to paction=parsefragment [23:42:20] the rationale for T90374 was "Retrieving the page HTML via api.php is probably inefficient. We've observed that the time to first byte is very high (over a second, sometimes two) and the time spent transmitting data very low (a few hundred milliseconds)." [23:42:39] but loading VE and looking at the network inspector, I see a request for https://en.wikipedia.org/w/api.php?action=visualeditor&format=json&paction=metadata&page=foo&uselang=en [23:43:02] is the restbase request concurrent? [23:43:05] or is it blocked on that? [23:44:16] hm [23:44:32] looking at the code that appears to be concurrent [23:45:28] is the TTFB for the action=metadata request substantially lower than the TTFB for page HTML? [23:46:26] it's about the same, IIRC [23:46:35] see https://grafana.wikimedia.org/dashboard/db/visualeditor-load-save [23:46:36] if they're currently both necessary for loading the editor, then you are literally getting the worst of both worlds [23:47:30] in old browsers, assuming they have maxed out their concurrent connections [23:48:00] or are you concerned about client side per-request cpu overhead? [23:48:37] my memory is a bit hazy, but when I last looked, slow TTFB for api.php was caused by CommonSettings.php / InitializeSettings.php being in file-scope and not being eligible for jitting [23:49:31] so you don't really save much by moving most of the payload to a separate request (even if async) so long as you retain the dependency on the API [23:49:44] brb [23:49:59] well, you start your large content transfer as soon as you can [23:50:27] while the relatively small metadata request is still slow to get started, it at least won't take long to transfer [23:50:31] I don't have particularly useful metrics on this, I just loaded VE on w:en:Barack_Obama once and the API TTFB was much higher [23:51:15] which API? [23:51:49] ori, wouldn't the config file-scope thing be relevant to index.php requests as well as the API? [23:52:21] per-request overheads in the PHP API have always been 40+ms [23:52:34] We might not save save much by splitting the RB call while we still depend on the API, but on the other hand we probably don't lose much either? [23:52:55] https://grafana.wikimedia.org/dashboard/db/api-summary?panelId=2&fullscreen [23:59:47] sounds to me like we can afford to run a few extra restbase queries in parallel