tags on that page :S [18:58:49] yeah I have no idea what they're doing... [19:00:13] 10VisualEditor, 10VisualEditor-EditingTools: VisualEditor: Pressing delete on an indented list item does not unindent it rather merges it with the previous item in a numbered list - https://phabricator.wikimedia.org/T65051#1126079 (10Etonkovidova) p:5Triage>3Normal [19:03:12] (03PS1) 10Alex Monk: Fix action.abort.mechanism value in ViewPageTarget#onUnload [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/197391 (https://phabricator.wikimedia.org/T92869) [19:05:45] milimetric, should we put that in wmf21? [19:21:13] (03CR) 10Catrope: [C: 032] Fix action.abort.mechanism value in ViewPageTarget#onUnload [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/197391 (https://phabricator.wikimedia.org/T92869) (owner: 10Alex Monk) [19:21:22] (03PS1) 10Jforrester: Fix action.abort.mechanism value in ViewPageTarget#onUnload [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197393 (https://phabricator.wikimedia.org/T92869) [19:22:21] (03CR) 10Krinkle: [C: 032] "Confirmed locally. Without this patch, navigating away after making a change results in:" [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/197391 (https://phabricator.wikimedia.org/T92869) (owner: 10Alex Monk) [19:23:28] (03Merged) 10jenkins-bot: Fix action.abort.mechanism value in ViewPageTarget#onUnload [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/197391 (https://phabricator.wikimedia.org/T92869) (owner: 10Alex Monk) [19:23:40] 10VisualEditor, 3VisualEditor 2014/15 Q3 blockers: Move oldid/timestamp inference from API module to client-side JS - https://phabricator.wikimedia.org/T92993#1126137 (10Catrope) 3NEW [19:24:02] 10VisualEditor, 10VisualEditor-Performance, 5Patch-For-Review, 3VisualEditor 2014/15 Q3 blockers: Retrieve page HTML directly from RESTbase - https://phabricator.wikimedia.org/T90374#1126144 (10Catrope) [19:24:03] 10VisualEditor, 3VisualEditor 2014/15 Q3 blockers: Move oldid/timestamp inference from API module to client-side JS - https://phabricator.wikimedia.org/T92993#1126145 (10Catrope) [19:24:09] 10VisualEditor, 3VisualEditor 2014/15 Q3 blockers: Move oldid/timestamp inference from API module to client-side JS - https://phabricator.wikimedia.org/T92993#1126137 (10Catrope) [19:24:48] 10VisualEditor, 3VisualEditor 2014/15 Q3 blockers: Move oldid/timestamp inference from API module to client-side JS - https://phabricator.wikimedia.org/T92993#1126149 (10Jdforrester-WMF) p:5Triage>3High [19:24:50] Hmm. [19:25:00] Krenair: Does ^^^ look like fun to you? ;-) [19:28:55] James_F, hm [19:29:01] :-) [19:29:09] I'll take that as a 'no'? [19:29:33] Krenair: sure, the sooner it goes in the fewer events I have to backfill / babysit [19:29:59] (03CR) 10Jforrester: [C: 032] Fix action.abort.mechanism value in ViewPageTarget#onUnload [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197393 (https://phabricator.wikimedia.org/T92869) (owner: 10Jforrester) [19:30:20] James_F, Number.parseInt( ve.init.target.doc.head.querySelector( '[rel="dc:replaces"]' ).getAttribute( 'resource' ).replace( 'mwr:revision/', '' ) ) [19:30:59] Krenair: 202313 [19:31:20] wait, I think that's wrong >_> [19:31:59] (03Merged) 10jenkins-bot: Fix action.abort.mechanism value in ViewPageTarget#onUnload [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197393 (https://phabricator.wikimedia.org/T92869) (owner: 10Jforrester) [19:32:36] James_F, looking at ve.init.target.doc.head.children that's the only obvious thing about revision numbers [19:32:44] but I'm pretty sure it refers to the previous revision [19:32:56] rather than the current oen [19:32:59] one* [19:34:32] edsanders: we'll start in a few mins, trevor, roan and moriel are still eating lunch [19:34:59] James_F, and time? [19:35:07] I don't think these things are already in the parsoid head [19:36:26] Krenair: the current revision is referenced in about="http://en.wikipedia.org/wiki/Special:Redirect/revision/651634886" [19:36:34] on the html element [19:39:49] (03PS2) 10Physikerwelt: Fix problems with the Search interface [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197316 [19:39:52] (03CR) 10jenkins-bot: [V: 04-1] Fix problems with the Search interface [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197316 (owner: 10Physikerwelt) [19:41:38] (03PS3) 10Physikerwelt: Fix problems with the Search interface [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197316 [19:41:41] (03CR) 10jenkins-bot: [V: 04-1] Fix problems with the Search interface [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197316 (owner: 10Physikerwelt) [19:42:07] (03PS13) 10Mooeypoo: Reorganize api calls and add sourceHandler and error message [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/194991 (https://phabricator.wikimedia.org/T91730) [19:42:50] (03CR) 10jenkins-bot: [V: 04-1] Reorganize api calls and add sourceHandler and error message [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/194991 (https://phabricator.wikimedia.org/T91730) (owner: 10Mooeypoo) [19:45:00] 10OOjs-UI, 10VisualEditor, 10VisualEditor-EditingTools, 7Regression: [Regression pre-wmf22 ]Template dialog has footer line crossing through button - https://phabricator.wikimedia.org/T92986#1126221 (10Ryasmeen) p:5Triage>3High [19:47:20] (03CR) 10Physikerwelt: [C: 032 V: 032] Fix problems with the Search interface [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197316 (owner: 10Physikerwelt) [19:51:20] 10VisualEditor: Visual Editor default configuration - https://phabricator.wikimedia.org/T90854#1126227 (10Syleas) You have to configure 2 wiki on the same server. In order to have only one folder with mediawiki code, I create symbolic link in the folder. The issue I have is even if i configure the correct parso... [19:56:18] 10VisualEditor: [Regression pre-wmf22] No gap between Button labels and icons in Media Settings>Advanced dialogs - https://phabricator.wikimedia.org/T93002#1126251 (10Ryasmeen) 3NEW [19:56:38] 10VisualEditor: [Regression pre-wmf22] No gap between Button labels and icons in Media Settings>Advanced Settings dialog - https://phabricator.wikimedia.org/T93002#1126259 (10Ryasmeen) [19:59:47] 10VisualEditor, 10VisualEditor-EditingTools, 10VisualEditor-Performance, 7Performance, 3VisualEditor 2014/15 Q3 blockers: On VisualEditor load, async pre-load all the TemplateData for the page to make editing templates speedier - https://phabricator.wikimedia.org/T66772#1126273 (10Krinkle) a:5Krinkle>... [20:00:34] 10VisualEditor, 10VisualEditor-EditingTools, 10VisualEditor-Performance, 7Performance, 3VisualEditor 2014/15 Q3 blockers: On VisualEditor load, async pre-load all the TemplateData for the page to make editing templates speedier - https://phabricator.wikimedia.org/T66772#682539 (10Krinkle) Unassigning for... [20:02:25] (03PS1) 10Jforrester: Load RL modules in one load.php request, rather than in two stages [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197402 (https://phabricator.wikimedia.org/T53569) [20:02:35] 10VisualEditor: When the invalid format if URL is used inside link inspector the "Open" button looks disabled but it is clickable and clicking on it opens another tab trying loading the page with invalid URL - https://phabricator.wikimedia.org/T93003#1126290 (10Ryasmeen) 3NEW [20:02:57] 10VisualEditor: When the invalid format of URL is used inside link inspector the "Open" button looks disabled but it is clickable and clicking on it opens another tab trying loading the page with invalid URL - https://phabricator.wikimedia.org/T93003#1126297 (10Ryasmeen) [20:05:42] 10VisualEditor: When the invalid format of URL is used inside link inspector the "Open" button looks disabled but it is clickable and clicking on it opens another tab trying loading the page with invalid URL - https://phabricator.wikimedia.org/T93003#1126305 (10Ryasmeen) [20:06:32] gwicke, thanks [20:06:35] James_F, gwicke Number.parseInt( ve.init.target.doc.children[0].getAttribute( 'about' ).match( /revision\/([0-9]{0,})$/ )[1] ); [20:07:51] Krenair: That seems to work for me. [20:08:12] don't really like having to parse the url like that [20:09:36] (03PS14) 10Mooeypoo: Reorganize api calls and add sourceHandler and error message [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/194991 (https://phabricator.wikimedia.org/T91730) [20:09:49] It's not great. [20:10:04] 10VisualEditor: Clicking on disabled "Open" button opens the same page in another tab where there is nothing in the textbox of link inspector - https://phabricator.wikimedia.org/T93004#1126337 (10Ryasmeen) 3NEW [20:10:14] why is this high priority, and a blocker? [20:10:27] Krinkle, I fixed the issues (+ the import issue) if it works for you, can you re-review? [20:10:43] oh this blocks restbase? [20:10:53] Krenair: Yeah. [20:11:05] Krenair: And we want this to be done for wmf23 at the latest. :-( [20:11:58] I wonder what problems RoanKattouw_away things we'd run into with this [20:12:02] it's marked as 8 points [20:15:45] It blocks using RESTbase directly [20:16:33] Because as I said there is already a very slight chance of a race condition in ApiVisualEditor.php but this makes it /likely/ there will be a race condition [20:16:40] ok [20:16:54] So we need the basetimestamp [20:16:59] and whether the revision is current or not [20:17:02] Yeah I don't think the revision timestamp is in the right now [20:17:09] Yes, for the old edit notice hting [20:17:22] Although that we could circumvent by having the API return the newest revid I guess [20:18:53] gwicke, ^ [20:19:02] just need basetimestamp [20:19:31] unless we want to parse the revision ID out on the server side and look up the timestamp :/ [20:21:12] That would incur another round-trip to the server though :S [20:22:02] 10VisualEditor: Lookup is returning invalid url in Autofill Citation dialog - https://phabricator.wikimedia.org/T93005#1126396 (10Ryasmeen) 3NEW [20:28:15] (03PS1) 10Physikerwelt: Fix problems with basex search support [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 [20:28:52] Krenair, RoanKattouw: can you help me understand the problem? do you want to make sure to get the very latest version, even if it's newer than the revision the user started from? [20:29:05] gwicke: So, right now [20:29:19] we need the timestamp of the revision for edit conflict detection [20:29:21] iirc [20:29:51] If you request the latest version, we first have ApiVisualEditor.php look in the DB what the revid and timestamp are, and then sending a request to Parsoid, which means there's a possible race [20:30:03] (which I guess we could close by explicitly requesting a specific revid) [20:30:22] Soon, we will be hitting RESTbase directly from the client, which makes this race much more likely [20:30:39] which race are you worried about? [20:30:48] And we can't first ask the server what the latest revid is and then ask RESTbase for that ID, because that defeats the purpose of parallelization [20:30:53] an edit happening after you lock down the oldid? [20:30:53] gwicke: A new revision appearing in between [20:30:57] Yeah [20:31:01] 10VisualEditor: Lookup is returning invalid url in Autofill Citation dialog - https://phabricator.wikimedia.org/T93005#1126427 (10Mooeypoo) This is expected behavior. When the user fills something in the 'lookup' field, the service expects a certain format. If the service doesn't recognize the format (say, the s... [20:31:58] we do offer a way to retrieve the latest revision, but we don't currently re-check with the api for each request [20:32:08] so it might be a couple of seconds behind [20:32:13] basically if you want parsoid html to be editable without having to make a separate api request for more data, you need to provide the basetimestamp [20:32:50] VE has it's own API so we just provide the basetimestamp ourselves right now, but we want to get it from parsoid instead [20:32:54] I'm pretty sure we do store the timestamp [20:33:13] So yeah [20:33:24] this is the last-modified timestamp as provided in the revision? [20:33:36] The RESTbase response needs to contain the revid (which it already does by semi-accident) and the timestamp associated with that revision [20:33:41] Yeah it's rev_timestamp [20:33:45] corresponding to that rev_id [20:34:04] Because the edit API is stupid and has a timestamp-based rather than revid-based conflict detection interface :( [20:34:17] yeah, that's annoying [20:34:30] Oh, crap [20:34:32] It's worse [20:34:36] We need the latest-edit timestamp of the page [20:34:55] So if we're doing an oldid request for old page content, we still need the timestamp of the last edit [20:34:57] sigh [20:35:28] Because the edit API is stupid and has a timestamp-based rather than revid-based conflict detection interface :( [20:35:31] OTOH... in that case I guess we can just get it from the MW API in parallel [20:35:37] I wonder who did that. [20:35:39] :) [20:35:39] yeah, I was just going to say [20:35:50] But in the non-oldid case, we do need them to correspond [20:35:51] if you ask both the mw api & restbase for the same revision you should be okay [20:36:01] If we believe we're editing the latest version, then we need basetimestamp to be that version's timestamp [20:36:08] Yeah [20:36:16] But we can only do that in the oldid !== undefined case [20:36:20] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/31514 :D [20:36:44] RoanKattouw: is there a situation where the client doesn't know the oldid? [20:37:13] gwicke: Yes, if you're editing the latest version [20:37:24] To be fair that just passes it to the existing code that used timestamps [20:37:30] We do have wgCurRevId or whatever, but that is quite likely to be out of date [20:37:52] If the user opens a view page, spends 10 minutes reading the article, then clicks edit, we want to edit the latest version, not the version they read [20:37:55] RoanKattouw: isn't there some global JS variable that indicates the current view's revision? [20:38:00] (unless they were explicitly on an ?oldid=xyz view) [20:38:21] Which is why we explicitly disregard the JS variable with the latest revid [20:38:22] wgCurRevisionId [20:38:25] yeah [20:39:07] when do you need the timestamp [20:39:08] ? [20:39:26] could you get the content first & then figure out the timestamp from the revision on save? [20:39:48] Hmm yeah we could probably do that [20:40:07] So we should, [20:40:23] 1) extract the revid from the RESTbase response (which we can already do) [20:40:45] 10VisualEditor, 10Flow, 10Parsoid: ApiVisualEditor parsefragment behaves unexpectedly when context page has flow-board content model - https://phabricator.wikimedia.org/T92934#1126459 (10Mattflaschen) a:3Mattflaschen [20:40:55] 2) in parallel with the RESTbase request, ask the API for info about the latest revision; this'll tell us whether we need to show you the "this is an old version" edit notice [20:41:24] And oh wait there is no (3) because that's also basetimestamp in all cases [20:41:42] Or ... no [20:41:43] I'd prefer to avoid the API request just to get a timestamp :( [20:42:02] aren't you getting some other page metadata from the api already? [20:42:06] 3) if it was an old version but we didn't expect it to be one, we ... ugh [20:42:11] 10VisualEditor, 3VisualEditor 2014/15 Q3 blockers: Adding a template to an article on it.wp causes VE to freeze - https://phabricator.wikimedia.org/T90757#1126479 (10Mooeypoo) I can't reproduce this. Tested on - Win 8.1 Firefox 35 - Win 8.1 Opera 28 - Win7 Firefox 35 - Win7 Opera 27 - Ubuntu 14 Chrome 41.0.22... [20:42:13] Oh right [20:42:21] I'm being an idiot and gwicke is smart [20:42:33] We already have the ApiVisualEditor.php request, it can just be in there as part of the notices metadata [20:42:51] ah... I was only looking at getHTML :) [20:42:59] Right :) [20:43:10] So, the editingold notice is actually trivial to do client-side [20:43:25] the case where RB is out of date would be worth highlighting somehow, perhaps by logging it [20:43:35] (03PS1) 10Mattflaschen: Ensure wikitext is treated as such in PST [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/197412 (https://phabricator.wikimedia.org/T92934) [20:43:49] gwicke: It'll just trip the conflict handling, same as if the edit happened while you were editing [20:44:18] From the user's perspective it's no different, but in code we have to be careful [20:44:31] So [20:44:33] RoanKattouw: we could also offer a way to ask for RB to try really hard to get you the latest revision by asking the API before returning content [20:45:00] but in the common case it would be faster to just request it & then retry from VE if it's not the latest revision [20:45:07] Meh that's not worth it IMO [20:45:15] How out-of-date is RB really gonna be? [20:45:33] OnEdit updates are in a high-prio queue [20:45:33] So what I think we should do is this: [20:45:48] so low-single-digit seconds delay + parse time [20:46:03] for oldid requests, we request a specific revid from RB, and we request metadata for that same specific revid from the API, and the API also returns the basetimestamp, nothing can go wrong there [20:46:23] unless the job queue loses a job or RB has some issue while processing the update [20:46:49] for non-oldid (we think we have the latest version) requests, we get the latest revid along with its metadata from the API, and RB gives us a response that also encodes a revid. In the weird case where those revids don't match, we have to do another API request [20:47:11] So in that case we essentially just do optimistic parallelization [20:47:14] *nod* [20:47:41] We request the two in parallel expecting they'll be the same, and if we get differing results, we stick with what RB gave us and redo the API request [20:47:59] you could also ask RB for the newer revision [20:48:08] The only thing we need to deal with there is if the revid RB returned is not the latest, basetimestamp needs to be /its/ timestamp rather than the actual latest timestamp [20:48:17] (03CR) 10Hashar: "Apparently caused by some error on Gerrit side. The Zuul merger code has:" [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 (owner: 10Physikerwelt) [20:48:24] gwicke: But if that revision is not yet in storage, it'll be generated on-demand, right? [20:48:27] Which will be slow [20:48:34] yes, it might be slow [20:48:37] Does RB consolidate Parsoid requests in that case? [20:49:17] Varnish consolidates external requests, but not internal update requests as those don't pass through varnish [20:49:33] OK so that's vulnerable to a stampede [20:49:36] and RB doesn't currently have native consolidation [20:49:43] And for large pages, already very slow [20:50:09] it's vulnerable to two parses in parallel, assuming varnish consolidation works [20:50:27] one from the internal update request, the other from all external requests [20:51:13] the trade-off here is speed vs. probability of edit conflict in the case of starting the edit with a known-old revision [20:51:37] Right [20:51:49] Well Ori said earlier that for a Parsoid cache miss, loading Obama takes like a minute [20:51:50] (03CR) 10Physikerwelt: "recheck" [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 (owner: 10Physikerwelt) [20:52:01] We're able to load Obama in 7-8 seconds with a cache hit [20:52:21] parsing obama takes ~10 seconds on my laptop [20:52:22] 10VisualEditor, 10VisualEditor-ContentEditable, 3VisualEditor 2014/15 Q3 blockers, 5WMF-deploy-2015-03-18_(1.25wmf22): Deleting from an empty paragraph to the end of an inline node throws an exception - https://phabricator.wikimedia.org/T72375#1126508 (10Mooeypoo) [20:52:23] 10VisualEditor, 10VisualEditor-DataModel, 3VisualEditor 2014/15 Q3 blockers: VisualEditor: Deleting from a paragraph-terminating node to a paragraph-terminating node (?) is throwing "Unbalanced set of replace operations found" - https://phabricator.wikimedia.org/T74579#1126507 (10Mooeypoo) [20:52:23] So I'm strongly leaning towards using slightly stale content rather than aggressively trying to get up-to-date content [20:52:26] a bit longer on prod hardware [20:52:32] OK, well still [20:52:40] plus network transfer etc [20:52:40] That still makes the load 2-3x slower [20:52:48] Well network transfer is constant [20:52:49] 10VisualEditor: Link inspector wont open after clicking placing cursor on another link while the link inspector is open, cannot inspect any other existing link for that session - https://phabricator.wikimedia.org/T93011#1126510 (10Ryasmeen) 3NEW [20:52:57] Cached or not, you have to transfer the same amount of data [20:53:02] 10VisualEditor: Link inspector wont open after clicking placing cursor on another link while the link inspector is open, cannot inspect any other existing link for that session - https://phabricator.wikimedia.org/T93011#1126517 (10Ryasmeen) p:5Triage>3High [20:53:08] yeah [20:53:23] but, the probability of out-of-date content is pretty low with restbase [20:53:23] 10VisualEditor: Link inspector wont open after placing cursor on another link while the link inspector is open, cannot inspect any other existing link for that session - https://phabricator.wikimedia.org/T93011#1126522 (10Ryasmeen) [20:53:24] 10VisualEditor: Link inspector wont open after placing cursor on another link while the link inspector is open, cannot inspect any other existing link for that session - https://phabricator.wikimedia.org/T93011#1126521 (10Catrope) Is there an error in the console? [20:53:32] much lower than with Varnishes alone [20:53:40] Sure [20:54:02] and most pages aren't actually as large as Obama [20:54:09] 10VisualEditor: Link inspector wont open after placing cursor on another link while the link inspector is open, cannot inspect any other existing link for that session - https://phabricator.wikimedia.org/T93011#1126510 (10Ryasmeen) nope , I dont see any error [20:54:46] Well still though [20:54:52] Even if we push RB hard for the latest version [20:54:53] RoanKattouw: we also have some ideas on how to minimize the probability of miss on edit-after-save [20:54:57] There's still the potential for a race condition [20:55:08] by starting the parse from restbase even before saving the article [20:55:12] gwicke: Do we write Parsoid HTML directly into RB? [20:55:20] (when saving via VE) [20:55:32] 10VisualEditor, 3VisualEditor 2014/15 Q3 blockers: Adding a template to an article on it.wp causes VE to freeze - https://phabricator.wikimedia.org/T90757#1126528 (10Elitre) 5Open>3Invalid a:3Elitre Can't reproduce anymore. Will shout if this happens again. [20:55:34] no, we still parse from scratch [20:55:41] OK [20:55:45] but right now we only start doing so after the save went through [20:55:54] (03CR) 10Physikerwelt: "recheck" [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 (owner: 10Physikerwelt) [20:56:04] Well anyway [20:56:14] There is a race condition that we do have to address [20:56:22] a future 'save HTML' end point could start parsing right away, while attempting a save to the PHP API in parallel [20:56:22] The API and RB can return information about different revisions [20:56:50] *nod* [20:57:24] another variation could be to require a RB response at least as recent as wgCurRevisionId [20:57:50] Hmm that would be good [20:58:01] I mean we do want to go forward from wgCurRevisionId if possible, but never back [20:58:04] That shouldn't happen [20:58:17] So yes, we should be able to say "give us revision N or newer" [20:58:39] yeah [20:58:44] RoanKattouw: https://gerrit.wikimedia.org/r/#/c/197402/ [20:59:35] James_F, your input needed? https://phabricator.wikimedia.org/T93005 [20:59:39] RoanKattouw: as a first approximation you could do the second request to RB if the oldid doesn't check out [20:59:43] (03CR) 10Catrope: [C: 032] Load RL modules in one load.php request, rather than in two stages [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197402 (https://phabricator.wikimedia.org/T53569) (owner: 10Jforrester) [20:59:59] until we have native support for such a conditional request in RB [21:00:14] gwicke: Yeah that makes sense. If the oldids from RB and the API differ, we rerequest based on the newer one [21:00:53] So if the API gave us something newer than RB did, we repeat the RB request, and if the API gave us something older, we repeat the API request [21:01:19] 10VisualEditor, 10VisualEditor-Performance: Current status and retrospective of VisualEditor performance - https://phabricator.wikimedia.org/T93012#1126533 (10ori) 3NEW a:3ori [21:01:48] RoanKattouw: *nod*, makes sense [21:01:58] (03Merged) 10jenkins-bot: Load RL modules in one load.php request, rather than in two stages [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197402 (https://phabricator.wikimedia.org/T53569) (owner: 10Jforrester) [21:02:21] (03PS1) 10Jforrester: Send Parsoid API request immediately when user clicks edit [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197414 (https://phabricator.wikimedia.org/T90372) [21:02:34] (03CR) 10Catrope: [C: 032] Send Parsoid API request immediately when user clicks edit [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197414 (https://phabricator.wikimedia.org/T90372) (owner: 10Jforrester) [21:02:42] 10VisualEditor, 10Citoid: Lookup is returning invalid url in Autofill Citation dialog - https://phabricator.wikimedia.org/T93005#1126548 (10Jdforrester-WMF) [21:03:01] Krenair: OK, so three screenfuls of discussion later :P (sorry about that) do you feel like it's clear what you need to do, or do you want me to summarize? [21:03:33] RoanKattouw: https://gerrit.wikimedia.org/r/#/c/196366/ [21:03:36] I wasn't watching the rest of that conversation [21:03:58] what needs to be done? [21:04:03] OK so [21:04:45] (03Merged) 10jenkins-bot: Send Parsoid API request immediately when user clicks edit [extensions/VisualEditor] (wmf/1.25wmf21) - 10https://gerrit.wikimedia.org/r/197414 (https://phabricator.wikimedia.org/T90372) (owner: 10Jforrester) [21:04:56] This is going to be a bit strange pre-RB split I guess [21:05:26] So I'm wondering if we should write this logic in PHP and then move it to JS immediately after, or just skip the former and do both at the same time [21:05:46] I think doing them both at the same time will probably be better [21:05:57] RoanKattouw: Then https://gerrit.wikimedia.org/r/#/c/197412/ then https://gerrit.wikimedia.org/r/#/c/197073/ [21:06:03] edsanders: Could you look at https://gerrit.wikimedia.org/r/#/c/197135/1/src/ui/dialogs/ve.ui.SpecialCharacterDialog.js please? [21:06:26] Krenair: So one thing you can do easily is break out where the editingold notice is added [21:06:57] We only need that for oldid requests [21:07:08] ...except if the oldid == the latest revid, grr [21:08:49] Krenair: So, if you add fields to the API result for the latest revision's ID and timestamp [21:09:06] Krenair: Then you can move the editingold notice logic to the client [21:09:28] RoanKattouw: slight longshot, but any chance you could review ? It has +1s from Trevor and Brion [21:10:31] right [21:12:05] Krenair: You could then also, with a bit more effort, move the basetimestamp determination to the client: basetimestamp = latest revid's timestamp EXCEPT if we are editing a revision that we thought was the latest one (i.e. non-oldid request) but turns out not to be, in that case it's that rev's timestamp; you'll need to extract the revid from the Parsoid and compare with the latest revid [21:12:10] RoanKattouw: https://gerrit.wikimedia.org/r/#/c/194338/ [21:12:11] (03CR) 10Physikerwelt: [C: 032 V: 032] Fix problems with basex search support [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 (owner: 10Physikerwelt) [21:12:15] (03CR) 10jenkins-bot: [V: 04-1] Fix problems with basex search support [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 (owner: 10Physikerwelt) [21:14:30] 10VisualEditor: Link inspector does not close while placing the cursor on the same line (for empty line) and also it shifts the cursor to the left after typing the first character on CE while the inspector is open - https://phabricator.wikimedia.org/T93013#1126573 (10Ryasmeen) 3NEW [21:16:38] RoanKattouw: https://gerrit.wikimedia.org/r/197415 [21:26:36] 10VisualEditor: Link inspector wont open after placing cursor on another link while the link inspector is open, cannot inspect any other existing link for that session - https://phabricator.wikimedia.org/T93011#1126619 (10Mooeypoo) a:3TrevorParscal [21:28:55] 10VisualEditor: Selecting an inspector while another inspector is open shows both inspector buttons as 'clicked' - https://phabricator.wikimedia.org/T93016#1126625 (10Mooeypoo) 3NEW [21:29:16] 10VisualEditor: Selecting an inspector while another inspector is open shows both inspector buttons as 'clicked' - https://phabricator.wikimedia.org/T93016#1126632 (10Mooeypoo) a:3TrevorParscal [21:44:10] RoanKattouw: Note that the style/script re-order is imho still considered experimental and whether it improves or worsens performance in browsers anno 2015 is still uncertain. [21:44:26] I reached out on our behalf with Ori to Paul Irish [21:44:29] Still pending response [21:44:48] (03PS9) 10Physikerwelt: New hook MathFormulaPostRender (replaces MathFormulaRendered) [extensions/Math] - 10https://gerrit.wikimedia.org/r/189348 [21:44:52] I guess it's fine to let it go to master, beta and group0 to better see how it goes, but beware it's pending further investigation. [21:45:04] Krinkle: yeah, that was my thinking [21:45:07] And also how it interacts with caching, I'm not 100% it doesn't cause regressions. [21:45:18] like the startup module mismatch is something I hadn't foreseen. [21:45:34] Krinkle: but that's very specific to mw1017 [21:45:48] ori: Yeah, but other stuff might similarly rely on it [21:46:28] ? [21:46:34] And existing usage of makeLoaderConditionalScript() should also be evaluated. [21:46:40] https://github.com/search?q=makeLoaderConditionalScript+@wikimedia&type=Code&utf8=%E2%9C%93 [21:47:12] Looks like it's minimal but worth a look [21:47:53] makeLoaderConditionalScript hasn't changed, btw [21:48:10] ori: Yeah, but it's meaning has. [21:48:34] ori: If used in the , it won't work since other stuff like mw.config will be missing. [21:48:36] it still outputs if (window.mw), which will continue to be true for everything except the inline scripts above the startup module [21:48:52] Yeah [21:49:38] ori: Hehe, we could define .push = Function#bind(Function#call) [21:49:41] :P [21:49:45] And kill performance btw [21:50:00] 10VisualEditor, 10VisualEditor-MediaWiki, 7Verified-in-Phase2, 3VisualEditor 2014/15 Q3 blockers, 5WMF-deploy-2015-03-04_(1.25wmf20): Categories become "detached item" after clicking 'Cancel' button - https://phabricator.wikimedia.org/T89923#1126670 (10Krenair) >>! In T89923#1122157, @Etonkovidova wrote:... [21:50:57] Krinkle: I think the next step is to remove blocking JavaScript from . If you look at the current crop of top modules, it is hard to justify that the functionality they provide warrants the impact they have [21:51:07] and to make the startup module a lot smaller [21:53:05] Yeah we need to reduce the top queue [21:53:22] Or split out the parts that really need to be in the top into separate modules [21:54:20] Krinkle: There's a startup module mismatch for 5 mins after deploy as well, because new pages adding to _mwq will be served with an old startup module that doesn't consume _mwq [21:54:35] It may need a "touch startup.js" after deploy to work at all [21:54:53] We could have avoided this problem by deploying the startup module change separately, but it's only 5 minutes [21:55:21] I can submit that change separately and cherry-pick it [21:56:24] That would wokr [21:56:48] (03CR) 10Catrope: [C: 032] Ensure wikitext is treated as such in PST [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/197412 (https://phabricator.wikimedia.org/T92934) (owner: 10Mattflaschen) [21:57:11] is therea way to get a specific annotation from an annotationSet by its *class* rather than symbolic name ...? [21:57:54] mooeypoo: See getAnnotationsByName [21:57:58] Oh, crap [21:58:03] Ahm, well there's a filter method... [21:58:14] hm [21:58:17] Look at the /implementation/ of getAnnotationsByName and you'll see how [21:58:21] okay, is there a way to get the name from the class [21:58:33] .static.name [21:58:38] hm [21:58:56] Or if you want to include subclasses, you could do .filter( function ( annotation ) { return annotation instanceof ve.dm.WhateverAnnotation; } ); [21:58:57] (03Merged) 10jenkins-bot: Ensure wikitext is treated as such in PST [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/197412 (https://phabricator.wikimedia.org/T92934) (owner: 10Mattflaschen) [21:59:13] ori: I agree. Most of our top queue things don't need to be before the content. Except for certain style modules. [21:59:27] ori: Howeever a lot of our top queue things do need to run before the page is rendered. [21:59:40] To avoid a flash [22:00:00] Which is currently done by loading in the top and enqueing for dom-ready [22:00:12] which fires synchronously before the end of with jQueryready() [22:00:27] Krinkle: we could hide the body until the the end of [22:00:53] opacity transition [22:00:54] :D [22:01:18] (03CR) 10Cscott: [C: 031] "Looks okay, but since you are now passing the full parser context, extensions using the hook could break whenever the parser context API c" [extensions/Math] - 10https://gerrit.wikimedia.org/r/189348 (owner: 10Physikerwelt) [22:01:44] from top queue: .client-js body { opacity: 0; transition: opacity 1s ease; } and a setTimeout/on-ready race to addClass content-show [22:01:58] ori: Yeah, that way images can start loading [22:01:59] interesting [22:02:01] yep [22:02:08] And let's also re-evaluate our top queue stuff [22:02:11] and see what we can move [22:02:18] ori: btw, I created mw.hook for this purpose as well [22:02:31] to allow things to run sooner [22:02:36] we have to be bolder about mediawiki.legacy.*, IMO [22:02:40] ori: Also remember the async-top queue experimentation we did last year [22:02:44] that coudl be interesting to revive [22:02:53] RoanKattouw: ^ [22:02:59] What're we left on with that [22:03:14] Oh ahm [22:03:15] errr. not async top queue [22:03:17] What was that again? [22:03:21] I mean async bottom queue starting from the top [22:03:26] Oh that [22:03:33] MatmaRex: do you have any time to add something to your geshi RL work from last year? [22:03:36] That got reverted because it supposedly caused intermittent issues [22:03:45] RoanKattouw: disabled, not reverted. But yeah [22:03:47] It's still there [22:03:51] though no idea in what shape [22:03:51] ori: yes, tomorrow [22:04:11] cool, I'll file a task. [22:04:21] Krinkle: Could you review https://gerrit.wikimedia.org/r/#/c/197073/ ? [22:04:24] thanks, assign to me if it needs me, please [22:05:16] (03CR) 10Catrope: [C: 031] "Looks good to me, but you should address James's comment." [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/196366 (https://phabricator.wikimedia.org/T71727) (owner: 10Bartosz Dziewoński) [22:07:12] RoanKattouw: setTimeout(, 1800) [22:07:12] seconds [22:07:58] 10VisualEditor: Re-arranged (drag-drop) Categories become "detached item" after clicking 'Cancel' button - https://phabricator.wikimedia.org/T92861#1126694 (10Krenair) Actually on step 4, no categories are displayed. [22:08:58] Is etonkovidova around? [22:11:02] Krenair: She's WFH [22:11:16] But apparently not IRC :( [22:11:35] (03CR) 10Hashar: "recheck" [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 (owner: 10Physikerwelt) [22:12:39] MatmaRex: Do you want me to fix 196366? [22:12:45] MatmaRex: (Or are you already doing?) [22:13:07] James_F: you can now, or i will in an hour [22:13:11] (03CR) 10Physikerwelt: "@Cscott Yes, but that's good. Maybe someone figures out how to write a clever equation numbering extension. This should be unrelated to th" [extensions/Math] - 10https://gerrit.wikimedia.org/r/189348 (owner: 10Physikerwelt) [22:13:11] I'll do. [22:15:46] 10VisualEditor: Re-arranged (drag-drop) Categories become "detached item" after clicking 'Cancel' button - https://phabricator.wikimedia.org/T92861#1126714 (10Krenair) And on beta I seem to get different categories back at random. [22:16:07] (03CR) 10Hashar: "@Physikerwelt The Zuul repo was corrupted. I have dished it so that Zuul can reclone it from Gerrit. Works as intended now." [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197405 (owner: 10Physikerwelt) [22:20:29] (03PS3) 10Jforrester: Insert a new references list immediately, rather than showing a dialog [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/196366 (https://phabricator.wikimedia.org/T71727) (owner: 10Bartosz Dziewoński) [22:21:24] RoanKattouw: +2 https://gerrit.wikimedia.org/r/196366 please. :-) [22:21:35] (03PS1) 10Mooeypoo: Expand annotation beyond a word if it exists [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197425 (https://phabricator.wikimedia.org/T86399) [22:21:46] RoanKattouw, I could use your opinion on this ^^ [22:23:26] (03PS2) 10Mooeypoo: Expand annotation beyond a word if it exists [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197425 (https://phabricator.wikimedia.org/T86399) [22:23:53] (03CR) 10Catrope: [C: 04-1] "I once saw this when pasting in very complex content in Chrome, and couldn't reproduce it. But I did find out that this happens because fi" [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197375 (https://phabricator.wikimedia.org/T92969) (owner: 10MarkAHershberger) [22:24:10] 10VisualEditor, 10VisualEditor-ContentEditable, 5Patch-For-Review: VE in IE is stripping the contents of tags from pasted text - https://phabricator.wikimedia.org/T92969#1126731 (10Catrope) a:3Esanders [22:24:30] 10VisualEditor, 10Flow, 10Parsoid, 5WMF-deploy-2015-03-18_(1.25wmf22): ApiVisualEditor parsefragment behaves unexpectedly when context page has flow-board content model - https://phabricator.wikimedia.org/T92934#1126733 (10Jdforrester-WMF) 5Open>3Resolved [22:24:38] (03PS1) 10Trevor Parscal: Don't try to remove stuff we never added [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197426 (https://phabricator.wikimedia.org/T93011) [22:25:32] 10VisualEditor, 10VisualEditor-EditingTools, 5Patch-For-Review, 5WMF-deploy-2015-03-18_(1.25wmf22): Link inspector won't open after placing cursor on another link while the link inspector is open, cannot inspect any other existing link for that session - https://phabricator.wikimedia.org/T93011#1126739 (10J... [22:25:38] 10VisualEditor: Selecting an inspector while another inspector is open shows both inspector buttons as 'clicked' - https://phabricator.wikimedia.org/T93016#1126741 (10TrevorParscal) p:5Triage>3High [22:25:39] RoanKattouw, have any thoughts on how I would pass information from the target constructor to a widget (not necessarily directly)? [22:25:47] (03CR) 10Jforrester: [C: 031] Don't try to remove stuff we never added [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197426 (https://phabricator.wikimedia.org/T93011) (owner: 10Trevor Parscal) [22:25:53] 10VisualEditor, 3VisualEditor 2014/15 Q3 blockers: Selecting an inspector while another inspector is open shows both inspector buttons as 'clicked' - https://phabricator.wikimedia.org/T93016#1126625 (10TrevorParscal) [22:26:02] Right now we can have multiple targets on the page with different values here (it's a list of posters to the topic). [22:31:29] (03PS2) 10Catrope: Don't try to remove stuff we never added [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197426 (https://phabricator.wikimedia.org/T93011) (owner: 10Trevor Parscal) [22:33:01] Oh, is it just this.target? [22:36:43] (03CR) 10Jforrester: [C: 032] New hook MathFormulaPostRender (replaces MathFormulaRendered) [extensions/Math] - 10https://gerrit.wikimedia.org/r/189348 (owner: 10Physikerwelt) [22:37:56] (03Merged) 10jenkins-bot: New hook MathFormulaPostRender (replaces MathFormulaRendered) [extensions/Math] - 10https://gerrit.wikimedia.org/r/189348 (owner: 10Physikerwelt) [22:47:02] (03PS1) 10Physikerwelt: Update to new hook [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197429 [22:47:16] (03CR) 10jenkins-bot: [V: 04-1] Update to new hook [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197429 (owner: 10Physikerwelt) [22:47:26] (03PS2) 10Physikerwelt: Update to new hook [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197429 [22:47:36] (03CR) 10jenkins-bot: [V: 04-1] Update to new hook [extensions/MathSearch] - 10https://gerrit.wikimedia.org/r/197429 (owner: 10Physikerwelt) [22:48:16] (03PS3) 10Mooeypoo: Expand annotation beyond a word if it exists [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197425 (https://phabricator.wikimedia.org/T86399) [22:49:29] RoanKattouw: https://gerrit.wikimedia.org/r/#/c/197426/ and https://gerrit.wikimedia.org/r/197425 ktnxba]i. [22:49:51] [22:49:55] :-P [22:50:51] (03PS3) 10Catrope: Don't try to remove stuff we never added [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197426 (https://phabricator.wikimedia.org/T93011) (owner: 10Trevor Parscal) [22:51:37] (03CR) 10Catrope: [C: 032] Don't try to remove stuff we never added [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197426 (https://phabricator.wikimedia.org/T93011) (owner: 10Trevor Parscal) [22:52:28] (03PS1) 10Trevor Parscal: Auto-close inspectors [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/197432 (https://phabricator.wikimedia.org/T93016) [22:52:40] 10VisualEditor, 10VisualEditor-EditingTools, 10VisualEditor-MediaWiki-Links, 5Patch-For-Review, 3VisualEditor 2014/15 Q3 blockers: Wordbreak detection is faulty for selection starting just up-page of a link annotation - https://phabricator.wikimedia.org/T86399#1126799 (10Mooeypoo) a:5dchan>3Mooeypoo [22:53:30] 10VisualEditor, 10VisualEditor-EditingTools, 5Patch-For-Review, 3VisualEditor 2014/15 Q3 blockers, 5WMF-deploy-2015-03-18_(1.25wmf22): Link inspector won't open after placing cursor on another link while the link inspector is open, cannot inspect any other... - https://phabricator.wikimedia.org/T93011#1126801 [22:54:08] 10VisualEditor, 10VisualEditor-EditingTools, 5Patch-For-Review, 3VisualEditor 2014/15 Q3 blockers, 5WMF-deploy-2015-03-18_(1.25wmf22): Link inspector won't open after placing cursor on another link while the link inspector is open, cannot inspect any other... - https://phabricator.wikimedia.org/T93011#1126510 [22:54:17]