[00:03:11] (03PS3) 10Mooeypoo: [wip] Adding paramOrder widget to TemplateData editor [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/170655 [00:03:51] (03CR) 10jenkins-bot: [V: 04-1] [wip] Adding paramOrder widget to TemplateData editor [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/170655 (owner: 10Mooeypoo) [00:16:57] 3VisualEditor / 3ContentEditable: VisualEditor: shortcut(Ctrl+1) for Page Title does not work on Mac - 10https://bugzilla.wikimedia.org/73340 (10etonkovidova) 3NEW p:3Unprio s:3normal a:3None Betalabs and test2 In VE on Mac click Ctrl+1 which should insert Page Title - nothing happens. All other s... [00:44:59] whatami, hety [00:45:00] hey* [00:45:20] Hello, Krenair! [00:45:58] whatami, so https://bugzilla.wikimedia.org/show_bug.cgi?id=73320 [00:46:11] this is just inserting 'Cite book' as a template on english wikipedia, right? [00:46:31] with an isbn param? [00:46:40] Yes, I think so. [00:46:47] The original report is at WP:VE/F [00:47:04] Probably infoboxes, too. [00:47:13] I've pinged you in the thread, if you login over there [00:48:30] works for me [00:49:01] I haven't checked myself, and the report was pre-most-recent-deployment. [00:49:11] I can ask him if he's still seeing this. [00:50:07] can you check it? [00:51:31] Sure, Krenair. [00:51:36] thanks [00:53:05] I'll let you know if he says that it's still a problem. Otherwise, you can assume that he can't reproduce it any longer, either. [00:53:13] I've just checked and I can't get the red link myself. [00:55:58] 3VisualEditor / 3ContentEditable: VisualEditor: tables can be inserted into References list via Basic citation - 10https://bugzilla.wikimedia.org/73341 (10etonkovidova) 3NEW p:3Unprio s:3normal a:3None Created attachment 17106 --> https://bugzilla.wikimedia.org/attachment.cgi?id=17106&action=edit T... [01:32:44] (03PS1) 10Catrope: Explicitly bypass undefined values in oo.compare() [oojs/core] - 10https://gerrit.wikimedia.org/r/172929 [01:35:03] (03PS2) 10Catrope: Explicitly bypass undefined values in oo.compare() [oojs/core] - 10https://gerrit.wikimedia.org/r/172929 [01:46:38] (03PS6) 10Catrope: MenuWidget: Don't close menu when you click the scroll bar [oojs/ui] - 10https://gerrit.wikimedia.org/r/172723 (https://bugzilla.wikimedia.org/65774) (owner: 10Alex Monk) [01:49:15] (03CR) 10Catrope: [C: 032] MenuWidget: Don't close menu when you click the scroll bar [oojs/ui] - 10https://gerrit.wikimedia.org/r/172723 (https://bugzilla.wikimedia.org/65774) (owner: 10Alex Monk) [01:49:47] (03PS1) 10Catrope: Don't close PopupToolGroups when the scroll bar is clicked [oojs/ui] - 10https://gerrit.wikimedia.org/r/172933 (https://bugzilla.wikimedia.org/73284) [01:50:10] TrevorP|Away: https://gerrit.wikimedia.org/r/#/c/172933/ [01:51:19] (03Merged) 10jenkins-bot: MenuWidget: Don't close menu when you click the scroll bar [oojs/ui] - 10https://gerrit.wikimedia.org/r/172723 (https://bugzilla.wikimedia.org/65774) (owner: 10Alex Monk) [01:51:29] (03PS2) 10Catrope: Don't close PopupToolGroups when the scroll bar is clicked [oojs/ui] - 10https://gerrit.wikimedia.org/r/172933 (https://bugzilla.wikimedia.org/65774) [01:51:44] 3OOjs UI: OOjs UI: You can't click on a scrollbar to move down a suggestions list (MenuWidget result) to pick a lower item (because it closes on click) - 10https://bugzilla.wikimedia.org/65774#c6 (10Roan Kattouw) *** Bug 73284 has been marked as a duplicate of this bug. *** [01:51:44] 3VisualEditor / 3Editing Tools: VisualEditor: in category selector, clicking on scroll bar for drop down dismisses dropdown - 10https://bugzilla.wikimedia.org/73284#c7 (10Roan Kattouw) 5PATC>3RESO/DUP *** This bug has been marked as a duplicate of bug 65774 *** [01:52:27] mooeypoo: Icc6f38d2 [01:53:01] (03PS12) 10Mooeypoo: Eventify TemplateDataGenerator and use oojs-ui [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/167046 [01:53:18] (03PS4) 10Mooeypoo: [wip] Adding paramOrder widget to TemplateData editor [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/170655 [01:53:25] 3OOjs UI: OOjs UI: You can't click on a scrollbar to move down a suggestions list (MenuWidget result) to pick a lower item (because it closes on click) - 10https://bugzilla.wikimedia.org/65774#c9 (10Roan Kattouw) (In reply to Gerrit Notification Bot from comment #7) > Change 172723 merged by jenkins-bot: > Men... [01:53:32] (03CR) 10jenkins-bot: [V: 04-1] Eventify TemplateDataGenerator and use oojs-ui [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/167046 (owner: 10Mooeypoo) [01:56:41] (03CR) 10jenkins-bot: [V: 04-1] [wip] Adding paramOrder widget to TemplateData editor [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/170655 (owner: 10Mooeypoo) [02:16:28] (03PS5) 10Mooeypoo: [wip] Adding paramOrder widget to TemplateData editor [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/170655 [02:22:33] (03PS1) 10Catrope: Add getProp(), setProp() and isInstanceOfAny() [oojs/core] - 10https://gerrit.wikimedia.org/r/172939 [02:24:32] (03PS1) 10Catrope: Replace ve.getProp(), ve.setProp() and ve.isInstanceOfAny() with OO aliases [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172940 [02:26:23] (03CR) 10jenkins-bot: [V: 04-1] Replace ve.getProp(), ve.setProp() and ve.isInstanceOfAny() with OO aliases [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172940 (owner: 10Catrope) [06:40:25] 3VisualEditor / 3MediaWiki integration: VisualEditor: Magic words like ISBN links in templates are rendered as red links now - 10https://bugzilla.wikimedia.org/73320#c1 (10WhatamIdoing) I can reproduce this at en.wp today, but not at en.wikipedia.beta.wmflabs.org, so presumably the problem has already been... [08:23:40] 3VisualEditor / 3Editing Tools: VisualEditor: [Regression wmf7] Deleted template parameters aren't actually deleted - 10https://bugzilla.wikimedia.org/73134#c14 (10Manuel) Confirmed, it works on itwiki (Chrome; VEctor; Win 8.1) [09:00:56] (03CR) 10Hashar: [C: 032] Fixed RuboCop Style/TrailingBlankLines offense [oojs/ui] - 10https://gerrit.wikimedia.org/r/172741 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:04:48] (03CR) 10Hashar: [C: 04-1] Fixed RuboCop Style/WordArray offense (031 comment) [oojs/ui] - 10https://gerrit.wikimedia.org/r/172742 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:05:13] (03CR) 10Hashar: [C: 032] Fixed RuboCop Style/SpaceAfterComma offense [oojs/ui] - 10https://gerrit.wikimedia.org/r/172740 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:06:17] (03CR) 10Hashar: [C: 032] Fixed RuboCop Style/NilComparison offense [oojs/ui] - 10https://gerrit.wikimedia.org/r/172739 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:07:47] (03CR) 10Hashar: "recheck" [oojs/ui] - 10https://gerrit.wikimedia.org/r/172734 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:08:04] (03CR) 10Hashar: [C: 032] Fixed RuboCop Style/SpaceAroundEqualsInParameterDefault offense [oojs/ui] - 10https://gerrit.wikimedia.org/r/172734 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:08:39] (03CR) 10Hashar: [C: 032] Fixed RuboCop Style/EmptyLines offense [oojs/ui] - 10https://gerrit.wikimedia.org/r/172731 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:09:02] (03CR) 10Hashar: [C: 032] Fixed RuboCop Style/AsciiComments offense [oojs/ui] - 10https://gerrit.wikimedia.org/r/172726 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [09:09:36] (03CR) 10Hashar: [C: 04-1] "-1 pending a Jenkins job to be added." [oojs/ui] - 10https://gerrit.wikimedia.org/r/172716 (https://bugzilla.wikimedia.org/72841) (owner: 10Zfilipin) [10:39:23] (03CR) 10Esanders: "ping" [oojs/ui] - 10https://gerrit.wikimedia.org/r/171548 (owner: 10Esanders) [11:01:55] 3VisualEditor / 3ContentEditable: VisualEditor: Safari - link inspector opens in a upper left corner - 10https://bugzilla.wikimedia.org/73336 (10Andre Klapper) [11:23:29] (03PS1) 10Esanders: Use .super in nodes and annotations [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172975 [11:25:51] (03PS2) 10Esanders: Use .super in nodes, annotations, meta and lineardata implementations [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172975 [11:31:26] 3VisualEditor / 3ContentEditable: VisualEditor: Drag-and-drop of a block image into a table slices the table rather than inserting inside the cell - 10https://bugzilla.wikimedia.org/73318 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low [11:33:25] 3VisualEditor / 3Data Model: VisualEditor: [Regression wmf1] Increasing indentation to a bullet/numbered list is also adding a slug with a new bullet/numbered point each time - 10https://bugzilla.wikimedia.org/71134#c7 (10James Forrester) (In reply to Mark A. Hershberger from comment #6) > This is probably p... [11:45:40] 3VisualEditor / 3Editing Tools: VisualEditor: Tables inside references aren't allowed in wikitext (but are in VE and Parsoid) - 10https://bugzilla.wikimedia.org/73341 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low [11:49:25] 3VisualEditor / 3ContentEditable: VisualEditor: shortcut(Ctrl+1) for Page Title does not work on Mac - 10https://bugzilla.wikimedia.org/73340#c1 (10James Forrester) 5NEW>3RESO/WOR Works for me in Safari 8, Chrome 38 and Firefox 33. What browser were you using? [11:52:41] 3VisualEditor / 3Editing Tools: VisualEditor: Style invalid MWTitleInputWidgets - 10https://bugzilla.wikimedia.org/72970#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Normal s:5normal>3enhanc (In reply to Roan Kattouw from comment #0) > Should we style MWTitleInputWidgets with invalid contents wit... [11:53:25] 3MediaWiki extensions / 3TemplateData: TemplateData: TemplateData should have a parameter to support Wikidata - 10https://bugzilla.wikimedia.org/67659 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Normal [11:54:41] 3MediaWiki extensions / 3TemplateData: TemplateData: Localise names of types in the HTML rendering (string, wiki-page-name, ...) - 10https://bugzilla.wikimedia.org/59745 (10James Forrester) 5REOP>3ASSI a:5Moriel Schottlender>3None [11:56:25] 3MediaWiki extensions / 3TemplateData: TemplateData.hooks.php:71: MWException: Invalid callback in hooks for ParserFirstCallInit - 10https://bugzilla.wikimedia.org/68699#c1 (10James Forrester) 5NEW>3RESO/WOR Is Wikibase interfering with TemplateData's hook somehow? Marking as WFM as I couldn't reproduce... [11:57:55] 3OOjs UI / 3Technical Debt: OOjs UI: TextInputWidget auto-resize method is a little inefficient - 10https://bugzilla.wikimedia.org/73328#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low s:5normal>3enhanc (In reply to Mark Holmquist from comment #0) > Quoth Roan, OOJS-UI creates and measures a clo... [12:00:26] 3MediaWiki extensions / 3TemplateData: TemplateData.hooks.php:71: MWException: Invalid callback in hooks for ParserFirstCallInit - 10https://bugzilla.wikimedia.org/68699#c2 (10Nemo) (In reply to James Forrester from comment #1) > Is Wikibase interfering with TemplateData's hook somehow? Maybe; did you have... [12:01:55] 3VisualEditor / 3ContentEditable: VisualEditor: Drag-and-drop of a block image doesn't remove the marker lines sometimes (?) - 10https://bugzilla.wikimedia.org/73275 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Normal [12:03:10] 3VisualEditor / 3ContentEditable: VisualEditor: Display of several float:left-ed tables side-by-side inserts slugs that break them up - 10https://bugzilla.wikimedia.org/52304 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low s:5normal>3minor [12:08:10] 3OOjs UI / 3Technical Debt: OOjs UI: TextInputWidget auto-resize method is a little inefficient - 10https://bugzilla.wikimedia.org/73328#c2 (10Mark Holmquist) Indeed on some level it is - I used this method to fix UW's auto-resize ability. But I think there are avenues to making it faster that don't require... [12:09:09] marktraceur: You're up early. :-) [12:09:15] Hey mvolz. [12:09:55] I'm up normal, really [12:10:04] James_F: 06:00 every day or something [12:10:11] hey James_F [12:10:12] Though I have been slacking terribly lately [12:10:14] computer issues [12:10:18] marktraceur: Same for me, TBF. :-) [12:10:21] mvolz: Boo. :-( [12:10:21] finally managed to get it started up [12:10:21] James_F: It will help me sleep on the plane later [12:10:31] marktraceur: You're off somewhere? [12:10:35] AMS [12:10:41] 11 hours from now [12:10:43] For the GLAM thing? [12:10:47] Yessir [12:10:47] Or just randomly? [12:10:59] Aha. We lost Krinkle|detached and JeanFred for that too. [12:11:08] Neat. [12:11:18] Wait, you lost JeanFred? I didn't know you had 'im. [12:14:43] 3VisualEditor / 3ContentEditable: VisualEditor: Editing surface displays non-existent spaces after bullet points in Thai Wikipedia - 10https://bugzilla.wikimedia.org/52291#c3 (10James Forrester) 5NEW>3RESO/INV This is because the Thai Wikipedia has this CSS in its Common.css: | /* A request by octahedro... [12:16:11] 3VisualEditor / 3MediaWiki integration: VisualEditor: Magically support Extension:InputBox's content for BLP warning notices on enwiki - 10https://bugzilla.wikimedia.org/54029 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Lowest [12:17:45] marktraceur: We don't. [12:18:07] Aww. I wanted to go to the GLAM thing too but my BIL is visiting so we're doing the tourist thing with him. Bletchely Park and Stonehenge. [12:18:27] 3VisualEditor / 3Data Model: VisualEditor: Duplicating categories (and possibly also something else) - 10https://bugzilla.wikimedia.org/54169#c4 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low Think this was all fixed [12:18:56] 3VisualEditor / 3ContentEditable: VisualEditor: Dimensions of small images are lost in rendering - 10https://bugzilla.wikimedia.org/54205#c1 (10James Forrester) 5NEW>3RESO/FIX Fixed in 2013. [12:19:55] 3VisualEditor / 3MediaWiki integration: VisualEditor: Long lines in preformatted paragraphs should not wrap in VE - 10https://bugzilla.wikimedia.org/54381#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low Alternatively we could fix this bug in MediaWiki… [12:23:40] 3VisualEditor: VisualEditor: Behaviour of

 tags - 10https://bugzilla.wikimedia.org/54382#c1 (10James Forrester) 5NEW>3RESO/INV Content that is pre-formatted is not wrapped in  tags but with space-indented-preformatting, which does work with wikitext structures.
[12:24:41] 	 3VisualEditor / 3MediaWiki integration: VisualEditor: Category editing tool should preview or at least link to the input categories - 10https://bugzilla.wikimedia.org/54656#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Normal s:5normal>3enhanc Seems like a nice idea. Provide a link in the category...
[12:25:40] 	 3VisualEditor / 3Initialisation: VisualEditor: Show percentage of progress in loading animation - 10https://bugzilla.wikimedia.org/54225#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Normal s:5normal>3enhanc Not sure how we'd judge progress on this one, but it'd be useful for users…
[12:28:11] 	 3VisualEditor / 3Editing Tools: VisualEditor: Dropdown clipping is a bit too aggressive - 10https://bugzilla.wikimedia.org/54705#c2 (10James Forrester) 5NEW>3RESO/FIX p:5Unprio>3Normal a:3Trevor Parscal Fixed in OOjs UI with gerrit 157295.
[12:31:25] 	 3VisualEditor / 3ContentEditable: VisualEditor:Math formula does not appear immediately after copy-paste in test2 - 10https://bugzilla.wikimedia.org/58713#c1 (10James Forrester) 5NEW>3RESO/FIX p:5Unprio>3Normal We fixed this a while ago. :-)
[12:37:55] 	 3VisualEditor / 3ContentEditable: VisualEditor: Reconsider whether you should be able to replace a selected node by typing / insertion tools - 10https://bugzilla.wikimedia.org/69422#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Lowest s:5normal>3enhanc (In reply to Spinningspark from comment #0) >...
[12:39:36] 	 edsanders|away: http://en.wikipedia.beta.wmflabs.org/wiki/User:Jdforrester_(WMF)/Sandbox?veaction=edit
[12:44:54] 	 (03PS3) 10Esanders: Use .super in nodes, annotations, meta and lineardata implementations [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172975 
[12:46:10] 	 3VisualEditor / 3ContentEditable: VisualEditor: The text is going out of the border of the page for a lengthy content in math inspector - 10https://bugzilla.wikimedia.org/56637#c1 (10James Forrester) 5NEW>3RESO/INV This is ultimately up to the control of the user, and so not really a "bug".
[12:47:11] 	 3VisualEditor / 3ContentEditable: VisualEditor: ↵ is shown when wikicode contains single newline, which is not very WYSIWYG - 10https://bugzilla.wikimedia.org/48290#c10 (10James Forrester) *** Bug 57454 has been marked as a duplicate of this bug. ***
[12:47:11] 	 3VisualEditor / 3ContentEditable: VisualEditor:A Return character appears when a text is followed by  $code - 10https://bugzilla.wikimedia.org/57454#c2 (10James Forrester) 5NEW>3RESO/DUP   *** This bug has been marked as a duplicate of bug 48290 ***
[12:48:41] 3VisualEditor / 3Editing Tools: VisualEditor: "Merge cells" option should be in a selection context menu, not the toolbar - 10https://bugzilla.wikimedia.org/73228 (10James Forrester) 5UNCO>3ASSI p:5Unprio>3Normal s:5normal>3enhanc
[12:50:41] 3VisualEditor / 3ContentEditable: VisualEditor: "Unbalanced set of replace operations found" when deleting table cells - 10https://bugzilla.wikimedia.org/63103#c1 (10James Forrester) 5NEW>3RESO/FIX a:3Ed Sanders This should now be fixed with the new table editing code that replaces this broken issue.
[12:52:26] 3VisualEditor: VisualEditor:  Odd removal of table inside an image caption - 10https://bugzilla.wikimedia.org/61064#c1 (10James Forrester) 5NEW>3RESO/WOR Probably a browser bug or flakiness.
[12:55:00] 3VisualEditor / 3ContentEditable: VisualEditor: Possible to delete a table's rows and columns but not the table, which is now invisible in VE but retains the wikitext - 10https://bugzilla.wikimedia.org/69706 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low s:5normal>3minor
[12:57:12] 3VisualEditor / 3ContentEditable: Visual Editor: Tables - saved tables look much smaller than in VE and display grayish background - 10https://bugzilla.wikimedia.org/72784#c2 (10James Forrester) 5NEW>3RESO/DUP This is just Tidy breaking table rendering, as before.  *** This bug has been marked as a dupli...
[12:57:12] 3VisualEditor / 3ContentEditable: VisualEditor: Tables - multiple colspan and rowspan are not displayed correctly - 10https://bugzilla.wikimedia.org/72790#c6 (10James Forrester) *** Bug 72784 has been marked as a duplicate of this bug. ***
[12:58:10] 3VisualEditor / 3Editing Tools: VisualEditor: Table with some template-generated rows appears with additional jumbled empty table cells – enwiki's {{Singlechart}} template - 10https://bugzilla.wikimedia.org/68306 (10James Forrester)
[13:00:13] 3VisualEditor / 3ContentEditable: VisualEditor: Tables - adding formatted headings  to displays Uncaught TypeError - 10https://bugzilla.wikimedia.org/72816#c1 (10James Forrester) 5NEW>3RESO/FIX p:5Unprio>3Low a:3Ed Sanders Fixed in master.
[13:00:41] 3VisualEditor / 3ContentEditable: VisualEditor: Tables Caption - moving a cursor with keyboard forces a cursor to the begininng of the page - 10https://bugzilla.wikimedia.org/73055 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low s:5normal>3minor
[13:03:25] 3VisualEditor / 3Editing Tools: VisualEditor: Merging cells across table sections causes some cells to disappear - 10https://bugzilla.wikimedia.org/73222#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low Doesn't affect VE-MW because we don't use table sections there. Preventing merging probably makes...
[13:05:25] 3VisualEditor / 3MediaWiki integration: VisualEditor: Any changes made to an article by other users since switching into VE aren't reflected when switching back to read mode - 10https://bugzilla.wikimedia.org/59004 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low s:5normal>3minor
[13:06:25] 3VisualEditor / 3ContentEditable: VE: IE11 - opacity is flawed - 10https://bugzilla.wikimedia.org/72643 (10James Forrester) 5NEW>3ASSI
[13:06:26] 3VisualEditor / 3Initialisation: VisualEditor: Internet Explorer compatibility (tracking) - 10https://bugzilla.wikimedia.org/50085 (10James Forrester)
[13:06:43] mvolz: Bletchley and Stonehenge sounds great too. :-)
[13:07:40] 3VisualEditor / 3ContentEditable: VisualEditor: Some dialogs are showing with transparent backgrounds in IE11 - 10https://bugzilla.wikimedia.org/72643 (10James Forrester)
[13:10:10] 3VisualEditor / 3Data Model: VisualEditor: Deleting from a paragraph-terminating node to a paragraph-terminating node (?) is throwing "Unbalanced set of replace operations found" - 10https://bugzilla.wikimedia.org/72579 (10James Forrester) 5NEW>3ASSI
[13:13:26] 3VisualEditor: VisualEditor: 'mozMatchesSelector' called on an object that does not implement interface when launching VE - 10https://bugzilla.wikimedia.org/60504#c3 (10James Forrester) 5NEW>3RESO/WOR Can't reproduce this now (Firefox 33.1 with Firebug)…
[13:15:10] 3OOjs UI: OOjs UI: Toolbar menu width isn't working in IE11 any more - 10https://bugzilla.wikimedia.org/72592 (10James Forrester) 5NEW>3ASSI p:5Normal>3High
[13:17:27] 3OOjs UI: OOjs UI: [Regression] Menu width isn't working in IE11 any more – see VisualEditor's 'Page options' drop down menu - 10https://bugzilla.wikimedia.org/72640#c2 (10James Forrester) 5NEW>3ASSI p:5Low>3Normal Probably the same bug as bug 72592, but leaving distinct for now.
[13:17:27] 3VisualEditor / 3Data Model: VisualEditor: Deleting from a paragraph-terminating node to a paragraph-terminating node (?) is throwing "Unbalanced set of replace operations found" - 10https://bugzilla.wikimedia.org/72579 (10James Forrester)
[13:18:55] 3VisualEditor / 3Editing Tools: VisualEditor: Don't allow whitespace-only comments to be inserted - 10https://bugzilla.wikimedia.org/72561 (10James Forrester) 5NEW>3ASSI
[13:22:15] 3VisualEditor / 3Editing Tools: VisualEditor: Find a way to make the link button is more discoverable - 10https://bugzilla.wikimedia.org/69364 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low
[13:22:55] 3MediaWiki extensions / 3TemplateData: TemplateData: Generate and display to users frequency metrics on incomplete template data - 10https://bugzilla.wikimedia.org/69866 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Normal
[13:24:26] 3VisualEditor / 3Initialisation: VisualEditor: [Regression] Viewport sometimes scrolls to bottom when loading some pages in Chrome - 10https://bugzilla.wikimedia.org/73208 (10James Forrester) 5NEW>3ASSI p:5Unprio>3High a:3Ed Sanders
[13:25:45] (03PS1) 10Esanders: Initialize context's $element as hidden [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172983 (https://bugzilla.wikimedia.org/73208) 
[13:25:57] 3VisualEditor / 3Editing Tools: VisualEditor: There should be a link to the template page even if template description is available - 10https://bugzilla.wikimedia.org/70279 (10James Forrester) 5NEW>3ASSI p:5Unprio>3Low s:5normal>3enhanc
[13:27:58] 3VisualEditor: VisualEditor: Keyboard shortcut (ESC?) to quit the editor, bring back to read mode - 10https://bugzilla.wikimedia.org/73363 (10Elitre) 3NEW p:3Unprio s:3normal a:3None This was suggested by a user at fr.wp.
[13:34:41] 3VisualEditor / 3MediaWiki integration: VisualEditor: Keyboard shortcut (ESC?) to quit the editor, bring back to read mode - 10https://bugzilla.wikimedia.org/73363#c1 (10James Forrester) 5NEW>3ASSI p:5Unprio>3High s:5normal>3enhanc Sure.
[13:36:40] 3VisualEditor / 3MediaWiki integration: VisualEditor: Math rendering 2.0 does not work in edit mode - 10https://bugzilla.wikimedia.org/72539 (10James Forrester) 5PATC>3RESO/FIX
[13:46:13] 3VisualEditor: VisualEditor: Deploy to Tagalog Wikipedia (currently a Beta Feature there) - 10https://bugzilla.wikimedia.org/73365 (10Elitre) 3NEW p:3Unprio s:3normal a:3None See https://tl.wikipedia.org/wiki/Wikipedia:VisualEditor/Komentaryo#Did_you_know_why.3F .
[13:50:31] 3VisualEditor: VisualEditor:  Do not permit empty section headings (wikitext like == == or similar) - 10https://bugzilla.wikimedia.org/70368#c1 (10James Forrester) 5NEW>3RESO/DUP   *** This bug has been marked as a duplicate of bug 49452 ***
[13:50:31] 3VisualEditor / 3Data Model: VisualEditor: Whitespace-only headings should be collapsed to (blank) paragraphs - 10https://bugzilla.wikimedia.org/49452#c4 (10James Forrester) *** Bug 70368 has been marked as a duplicate of this bug. ***
[14:48:10] 3VisualEditor / 3ContentEditable: VisualEditor: Drag-and-drop in IE doesn't work (?) - 10https://bugzilla.wikimedia.org/73240 (10James Forrester) 5NEW>3ASSI p:5Unprio>3High
[14:52:41] 3VisualEditor / 3ContentEditable: VisualEditor: Safari - link inspector opens in a upper left corner - 10https://bugzilla.wikimedia.org/73336#c1 (10Ed Sanders) Safari browser bug. Applying patch upstream in rangefix.
[14:53:27] 3VisualEditor / 3Data Model: VE: [Regression]Gallery gets added to the table inside the image - 10https://bugzilla.wikimedia.org/73368 (10Ritu Swain) 3UNCO p:3Unprio s:3normal a:3None Created attachment 17115   --> https://bugzilla.wikimedia.org/attachment.cgi?id=17115&action=edit Caption gets added...
[14:54:27] 3VisualEditor / 3Data Model: VE: [Regression]Gallery gets added to the table inside the image - 10https://bugzilla.wikimedia.org/73368#c1 (10Ritu Swain) Also in FF 33.1.
[14:57:10] 3VisualEditor / 3ContentEditable: VisualEditor: Safari - white spaces are dropped for copied formatted text - 10https://bugzilla.wikimedia.org/73333#c1 (10Elitre) Duplicate of [[bug 71718]], I think.
[14:58:26] 3VisualEditor / 3Technical Debt: VisualEditor: Use mw.Api library in mw.Target - 10https://bugzilla.wikimedia.org/56659#c3 (10James Forrester) 5ASSI>3RESO/FIX a:3Rob Moen Done in https://gerrit.wikimedia.org/r/#/c/98713/ AFAICT.
[15:08:41] 3VisualEditor / 3Editing Tools: VisualEditor: [Regression pre-wmf4] All inspector dialog UI is broken when added inside Reference/Media Settings dialog box - 10https://bugzilla.wikimedia.org/64761#c6 (10Ritu Swain) Reopen this issue. In test2 and beta only.  steps-  1> open the link/math/comment/special char...
[15:11:12] 3VisualEditor / 3Editing Tools: VisualEditor: [Regression pre-wmf4] All inspector dialog UI is broken when added inside Reference/Media Settings dialog box - 10https://bugzilla.wikimedia.org/64761#c7 (10Ritu Swain) Created attachment 17116   --> https://bugzilla.wikimedia.org/attachment.cgi?id=17116&action=e...
[15:15:15] (03PS1) 10Esanders: Update RangeFix library 0.1.0 -> 0.1.1 [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/173007 (https://bugzilla.wikimedia.org/73336) 
[15:21:40] 3VisualEditor / 3ContentEditable: VisualEditor: Safari - white spaces are dropped for copied formatted text - 10https://bugzilla.wikimedia.org/73333#c2 (10Ed Sanders) Syntax fix: bug 71718
[15:21:57] 3VisualEditor / 3Editing Tools: VE:[Regression wmf8] Categorie names are in red font color. - 10https://bugzilla.wikimedia.org/73371 (10Ritu Swain) 3UNCO p:3Unprio s:3minor a:3None Created attachment 17117   --> https://bugzilla.wikimedia.org/attachment.cgi?id=17117&action=edit screenshot  Environmen...
[15:22:13] 3VisualEditor / 3Editing Tools: VE:[Regression wmf8] Categorie names are in red font color. - 10https://bugzilla.wikimedia.org/73372 (10Ritu Swain) 3UNCO p:3Unprio s:3minor a:3None Environment- test2, beta  1> Select Page Options -> Categories 2> In the Add a category type in a name and hit enter. Th...
[15:22:56] 3VisualEditor / 3Editing Tools: VE:[Regression wmf8] Categorie names are in red font color. - 10https://bugzilla.wikimedia.org/73372#c1 (10Ritu Swain) Created attachment 17118   --> https://bugzilla.wikimedia.org/attachment.cgi?id=17118&action=edit screenshot
[15:22:56] 3VisualEditor / 3Editing Tools: VE:[Regression wmf8] Categorie names are in red font color. - 10https://bugzilla.wikimedia.org/73372 (10Ritu Swain)
[15:32:20] (03CR) 10Zfilipin: [C: 032] [BrowserTest] make bullets test modern [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/172761 (owner: 10Cmcmahon)
[15:33:49] (03Merged) 10jenkins-bot: [BrowserTest] make bullets test modern [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/172761 (owner: 10Cmcmahon)
[15:57:40] 3VisualEditor / 3Editing Tools: VisualEditor: Plugin editors to be created (tracking) - 10https://bugzilla.wikimedia.org/46803#c2 (10Elitre) For documentation, see https://www.mediawiki.org/wiki/VisualEditor_gadgets.
[16:05:25]$ 3VERI Verified the fix in test2 and production.
[20:30:34] 	 cscott: action=sitematrix&format=json ?
[20:30:36] 	 https://en.wikipedia.org/w/api.php?action=sitematrix
[20:30:37] 	 it's WMF-specific though
[20:32:05] 	 legoktm: what does 'closed' mean in that output?
[20:32:28] 	 no one can edit the wiki except for stewards
[20:32:50] 	 https://wikimania2010.wikimedia.org/wiki/Main_Page
[20:33:52] 	 we should at least write a tool to autogenerate a static set of wiki configurations from that info.
[20:34:09] 	 i see it includes 'private' wikis as well.
[20:34:23] 	 what does 'fishbowl' mean?
[20:34:37] 	 public, but editing is restricted to people with accounts
[20:34:42] 	 and account creation is also restricted
[20:34:52] 	 http://meatballwiki.org/wiki/FishBowl :)
[20:34:59] 	 (03CR) 10Catrope: [C: 032] Use .super in nodes, annotations, meta and lineardata implementations [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172975 (owner: 10Esanders)
[20:37:16] 	 (03Merged) 10jenkins-bot: Use .super in nodes, annotations, meta and lineardata implementations [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/172975 (owner: 10Esanders)
[20:37:23] 	 (03PS15) 10Divec: Refactor SurfaceObserver pollOnceInternal [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/166188 
[20:37:27] 	 (03CR) 10jenkins-bot: [V: 04-1] Refactor SurfaceObserver pollOnceInternal [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/166188 (owner: 10Divec)
[20:40:15] 	 James_F, https://bugzilla.wikimedia.org/show_bug.cgi?id=59745 <-- this is done actually. The editor (both the new upcoming one and the existing one) use mw messages for the select box. The actual json sting isn't localized, but I think localizing the json string in light of having an editor should be a WONTFIX anyways?
[20:41:09] 	 So, it will be localized when you edit the json (as all the rest is localized, like the sting "Aliases" and such) but the actual json will be english json, as it is with all other stings (like, say, 'aliases' :p )
[20:43:29] 	 filed https://bugzilla.wikimedia.org/show_bug.cgi?id=73385 to get us to use sitewiki
[20:43:49] 	 (03CR) 10Catrope: [C: 032] When saving, return the full contentSub to the client [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/172746 (https://bugzilla.wikimedia.org/60718) (owner: 10Alex Monk)
[20:44:45] 	 mooeypoo: This isn't about the editor. It's about the table that shows on the read-mode page.
[20:44:52] 	 cscott: Thanks!
[20:45:11] 	 (03Merged) 10jenkins-bot: When saving, return the full contentSub to the client [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/172746 (https://bugzilla.wikimedia.org/60718) (owner: 10Alex Monk)
[20:45:22] 	 James_F, ohh
[20:45:50] 	 James_F, hm, since we already have those messages in the extension already -- isn't it trivial to use them in the table?
[20:45:55] 	 3VisualEditor / 3MediaWiki integration: VisualEditor: After saving a page, the FlaggedRevs notice "1 change in this version is pending review ..." is not shown - 10https://bugzilla.wikimedia.org/60718 (10James Forrester) 5PATC>3RESO/FIX
[20:46:00] * mooeypoo hasn't done the php message thing in a while
[20:46:03] 	 mooeypoo: Trivial fix is still a fix. ;-)
[20:46:06] * mooeypoo nods
[20:46:13] 	 mooeypoo: But yes, it sounds very easy to do.
[20:46:27] 	 I'll see if I can whip it up quickly. Working on the search widget now while I await review on my drag/drop
[20:46:36] 	 James_F, do you want me to implement the dragdrop to the categories?
[20:47:14] 	 mooeypoo: That'd be awesome, though maybe help Krenair do it so more than one person has ever implemented it? ;-)
[20:47:23] * mooeypoo nods
[20:47:56] 	 Krenair, whenever you want a quick walkthrough, let me know. It should be easy with the mixins, but might involve adding a specific functionality to the category widget itself.
[20:48:42] 	 Also that might answer my question about whether or not we want to add an empty bare-bones widget to ooui more than just the DragElement/DragGroupElement mixins
[20:52:02] 	 I'm still at college but should be back in half an hour
[20:54:16] 	 Take your time
[20:54:23] 	 Moriel and I need to stand in line for a thing in ~45 mins
[20:54:41] 	 3VisualEditor / 3ContentEditable: VisualEditor: Dimensions of small images are lost in rendering - 10https://bugzilla.wikimedia.org/54205#c2 (10etonkovidova) 5RESO/?>3VERI Re-checked on https://www.mediawiki.org/wiki/VisualEditor/Team - seems to be fixed.
[20:55:17] 	 Krenair, also, this may help: https://gerrit.wikimedia.org/r/#/c/170655/ (just look at the dragDropItemWidget and dragDropWidget for one way of how to implement the mixins)
[20:55:24] 	 Ignore the rest of the big files
[20:56:47] * James_F nods.
[20:58:12] 	 (03PS16) 10Divec: Refactor SurfaceObserver pollOnceInternal [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/166188 
[20:58:16] 	 (03CR) 10jenkins-bot: [V: 04-1] Refactor SurfaceObserver pollOnceInternal [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/166188 (owner: 10Divec)
[21:01:06] 	 TrevorP|Away: Trick question: if I were to have a this.results property (which is a widget), and also a this.$results property, what would you expect the relationship between those two properties to be?
[21:04:25] 	 3VisualEditor / 3ContentEditable: VisualEditor: White pawn "♙" appears on Alt+Shift+F in Firefox - 10https://bugzilla.wikimedia.org/69810 (10James Forrester) p:5Unprio>3High
[21:05:00] 	 TrevorParscal: https://gerrit.wikimedia.org/r/172933
[21:29:45] 	 ok, ve guys.  new  is active on parsoid.   is VE crying?
[21:30:05] 	 I'll go and check
[21:30:10] 	 thanks
[21:30:14] 	 (03PS1) 10Mooeypoo: Separate appendItems from addItems in GroupElement [oojs/ui] - 10https://gerrit.wikimedia.org/r/173105 
[21:30:48] 	 mooeypoo: Hey! Do you have a sec?
[21:30:51] 	 RoanKattouw: $results is a container, results is a select widget
[21:31:12] 	 Deskana, a couple, yeah, but we'll have to leave in a few. How can I help?
[21:31:16] 	 mooeypoo: I need someone that speak Hebrew.
[21:31:17] 	 mooeypoo: One sec.
[21:31:20] 	 TrevorParscal: Yup. And so $results !== results.$element
[21:31:35] 	 (03CR) 10Trevor Parscal: [C: 032] Don't close PopupToolGroups when the scroll bar is clicked [oojs/ui] - 10https://gerrit.wikimedia.org/r/172933 (https://bugzilla.wikimedia.org/65774) (owner: 10Catrope)
[21:31:45] 	 RoanKattouw: yeah, probably not the best naming
[21:31:55] 	 mooeypoo: We're messing around with Wikidata descriptions in the app. This involves changing capitalisation. I'm checking that it doesn't produce unexpected results in other languages.
[21:32:08] 	 RoanKattouw: but that container needs to be there iirc
[21:32:09] 	 mooeypoo: Does the grey text right at the end of this image look correct to you? http://i.imgur.com/VButTnS.png
[21:32:29] 	 mooeypoo: At the end of the bottom result.
[21:32:29] 	 Deskana, aye, looks right
[21:32:32] 	 TrevorParscal: Oh I believe it, I was just venting about the naming. I'm impressed you remember :)
[21:32:37] 	 mooeypoo: Cool! Thanks. :)
[21:32:48] 	 Not sure i'd phrase it this way, but it looks and reads Hebrew :D
[21:33:04] * Krenair is back now
[21:33:10] 	 mooeypoo: Yeah, the phrasing is outside our control. :-)
[21:33:21] 	 Indeed. 
[21:33:27] 	 Or, in other words -- no one's perfect, Deskana 
[21:33:29] 	 :D
[21:33:35] 	 Truth!
[21:34:46] 	 cscott: Everything looks fine to me
[21:35:14] 	 looks good to me too
[21:35:25] 	 lets see if that holds up
[21:35:37] 	 oh! and i should test OCG ;)
[21:35:58] 	 (03Merged) 10jenkins-bot: Don't close PopupToolGroups when the scroll bar is clicked [oojs/ui] - 10https://gerrit.wikimedia.org/r/172933 (https://bugzilla.wikimedia.org/65774) (owner: 10Catrope)
[21:36:14] 	 I gotta step out for a while but I have my work hangouts account on my phone, so if any fires break out let me know
[21:41:15] 	 3OOjs UI: OOjs UI: You can't click on a scrollbar to move down a suggestions list (MenuWidget result) to pick a lower item (because it closes on click) - 10https://bugzilla.wikimedia.org/65774 (10Alex Monk) 5PATC>3RESO/FIX
[21:47:50] 	 https://bugzilla.wikimedia.org/show_bug.cgi?id=56659#c3 - ... what?
[21:53:31] 	 3VisualEditor / 3Editing Tools: VisualEditor: [Regression wmf7] Deleted template parameters aren't actually deleted - 10https://bugzilla.wikimedia.org/73134#c15 (10etonkovidova) 5RESO/?>3VERI Verified in production.
[22:04:48] 	 MatmaRex: so, there are 22 RL modules that are currently being loaded using addModuleStyles
[22:04:51] 	 in core
[22:05:30] 	 not including skins
[22:05:54] 	 each of which I need to patch with a special config to not throw an error - that's the plan going forward
[22:07:00] 	 TrevorParscal: yeah, i've been thinking about that and i don't think it's realistic to change addModuleStyles() and such to throw exceptions
[22:07:13] 	 this is what I'm thinking
[22:07:14] 	 (unless we want to break tons of people's code, naturally)
[22:07:27] 	 this is also illuminative of the code quality out there: https://github.com/search?q=%40wikimedia+addmodulescripts&type=Code&utf8=%E2%9C%93
[22:07:29] 	 well, the idea was originally to detect when you were doing something wrong
[22:07:37] 	 like, including it statically and dynamically
[22:08:44] 	 my opinion is that we should just soft-deprecate addModuleStyles() and addModuleScripts(), and make addModules() smarter about CSS-only modules
[22:08:53] 	 yeah
[22:08:57] 	 I need to come up with a plan
[22:09:05] 	 possibly add some logging and such, but i bet right now the logging would flood WMF wikis, too
[22:09:15] 	 3VisualEditor / 3MediaWiki integration: VisualEditor:  Magic words like ISBN links in templates are rendered as red links now - 10https://bugzilla.wikimedia.org/73320#c2 (10James Forrester) 5NEW>3RESO/FIX p:5Unprio>3Normal Confirmed with http://en.wikipedia.beta.wmflabs.org/wiki/User:Jdforrester_(WMF...
[22:10:06] 	 and, we need a stop-gap for OOjs UI PHP, which is probably going to be to have the styles be sent 2x for to expect them to the be there and don't make the scripts depend on them at all
[22:10:51] 	 we could cook up some fancy workarounds for now
[22:10:58] 	 with a skip function, perhaps
[22:11:07] 	 depends on how evil we want to get
[22:11:09] 	 yeah, i'm just getting rather discouraged going through all this PHP code
[22:11:14] 	 I think you feel my pain there
[22:11:20] 	 i wonder if RL is turing-complete already?… ;)
[22:11:26] 	 lol
[22:12:33] 	 brb, late lunch
[22:12:47] 	 heh, we really could solve this rather neatly with a skip function
[22:25:03] 	 Krenair: Too bad we don't have substatuses for REOPENED like we do for RESOLVED
[22:25:11] 	 REOPENED WHATAREYOUSMOKING
[22:25:18] 	 (03PS1) 10Jforrester: Update OOjs UI to v0.1.0-pre (fe4076af75) [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/173178 
[22:25:31] 	 RoanKattouw: :-)
[22:25:42] 	 RoanKattouw: We won't have that in Phabricator, so…
[22:25:47] 	 (03CR) 10Catrope: [C: 032] Update OOjs UI to v0.1.0-pre (fe4076af75) [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/173178 (owner: 10Jforrester)
[22:25:54] 	 :D
[22:25:55] 	 Oy veh.
[22:26:02] 	 Hadn't even built the MW-core version yet.
[22:26:04] 	 Doesn't Fabricator have RESOLVED SPITE?
[22:26:13] 	 Oh heh that's why I can't find it
[22:26:27] 	 RoanKattouw: https://gerrit.wikimedia.org/r/173179
[22:26:38] 	 We definitely need to reopen https://bugzilla.wikimedia.org/show_bug.cgi?id=56659#c3 though, right?
[22:26:55] 	 We do?
[22:27:30] 	 James_F: That's what I was talking about reopening as WHATAREYOUSMOKING. I was surprised you responded so well to that jab :)
[22:27:52] 	 RoanKattouw: Oh. Context helps, you know.
[22:28:01] 	 (03Merged) 10jenkins-bot: Update OOjs UI to v0.1.0-pre (fe4076af75) [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/173178 (owner: 10Jforrester)
[22:28:16] 	 So the patch it was closed with doesn't appear to bear any relation to the bug, but OTOH I'm not so sure of the feasibility of fixing the bug
[22:28:22] 	 (03PS1) 10Jforrester: Update VE core submodule to master (0a42f21) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/173180 
[22:28:36] 	 RoanKattouw: The bug says "let's start using mw.Api".
[22:28:46] 	 Ooh
[22:28:48] 	 RoanKattouw: 6 months after we filed that bug, we added code that used mw.Api.
[22:28:50] 	 RoanKattouw: So…
[22:28:52] 	 I read "instead of" instead of "in"
[22:28:57] 	 Yeah... OK that's fair
[22:28:58] 	 RoanKattouw: Maybe I'm missing something?
[22:29:20] 	 The only thing you're missing is that the bug as it exists in my brain and Alex's !== the bug as it exists in BZ
[22:29:26] 	 For which you are forgiven :P
[22:29:35] 	 I accept your apologies.
[22:29:53] 	 RESOLVED WHATWASISMOKING
[22:30:16] 	 So let's reopen the bug and resummarise it as "Use mw.Api library in mw.Target instead of our own network functions"?
[22:30:42] 	 Why not create a new bug for that?
[22:30:54] 	 Otherwise it just gets confusing.
[22:30:58] 	 because that's what this bug was supposed to be for
[22:31:29] 	 Despite all evidence to the contrary in the bug… :-)
[22:31:59] 	 Reopened status exists for a reason, we shouldn't just make a new bug every time
[22:32:00] 	 3VisualEditor / 3Technical Debt: VisualEditor: Use mw.Api library in mw.Target instead of our own functions - 10https://bugzilla.wikimedia.org/56659 (10Alex Monk) 5RESO/FIX>3REOP
[22:32:13] 	 … but feel free to ignore me anyway.
[22:32:18] * James_F sighs.
[22:32:52] 	 TrevorP|Away, when you get back, any chance you'll have a few minutes for a hangout conversation? I have a bit of a problem with GroupElement/SearchWidget/SelectWidget that I have to ask you about before I dig a huge extending-everything-hole to myself.
[22:33:51] 	 Well the alternative is resolved wontfix because the original bug would have been pointless. :) "Use mw.Api library in mw.Target for some sort of new code because I like it"
[22:35:37] 	 (03PS1) 10Jforrester: Update VE core submodule to cherry-pick (ed45b77) [extensions/VisualEditor] (wmf/1.25wmf7) - 10https://gerrit.wikimedia.org/r/173183 
[22:36:02] 	 3VisualEditor / 3MediaWiki integration: VisualEditor:  Magic words like ISBN links in templates are rendered as red links now - 10https://bugzilla.wikimedia.org/73320#c3 (10etonkovidova) Created attachment 17122   --> https://bugzilla.wikimedia.org/attachment.cgi?id=17122&action=edit ISBN is  displayed in red
[22:36:51] 	 (03PS1) 10Jforrester: Update VE core submodule to cherry-pick (c48de3e) [extensions/VisualEditor] (wmf/1.25wmf8) - 10https://gerrit.wikimedia.org/r/173184 
[22:37:19] 	 Krenair: Before mw.Api I think we were rolling out own API request object, or something fun.
[22:37:36] 	 Krenair: It does mark progress from RoanKattouw's original code.
[22:38:33] 	 3VisualEditor / 3MediaWiki integration: VisualEditor:  Magic words like ISBN links in templates are rendered as red links now - 10https://bugzilla.wikimedia.org/73320#c4 (10etonkovidova) 5RESO/FIX>3REOP I copied   {{cite book|isbn=123456789X|url = http://www.amazon.com|title = Fish}} from http://en.wikip...
[22:39:30] 	 3VisualEditor / 3MediaWiki integration: VisualEditor:  Magic words like ISBN links in templates are rendered as red links now - 10https://bugzilla.wikimedia.org/73320#c5 (10James Forrester) 5REOP>3RESO/FIX (In reply to etonkovidova from comment #4) > I copied   > {{cite book|isbn=123456789X|url = http://...
[22:40:47] 	 mooeypoo: 
[22:40:50] 	 now good/
[22:40:51] 	 ?
[22:41:11] 	 yeah but I think I'm going to abandon my initial idea and go at it without killing anything.
[22:42:13] 	 Okay, so TrevorParscal uhm the main issue is this -- MediaSearchWidget should arrange objects into lines (sortof masonry view) when it displays. I was *hoping* to avoid going over the loop of items multiple times after addItems by intervening in the middle of addItems (just before the items are appended to the $group) and so I can do this appending myself
[22:42:24] 	 (03CR) 10Cmcmahon: "recheck" [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/173023 (owner: 10Cmcmahon)
[22:43:39] * James_F heads off.
[22:43:41] 	 however, this turns out to be a little insane. I sent a patch to ooui to separate 'appendItems' from addItems in GroupElement, but in order to override it in MediaSearchWidget, I need to override the *SelectWidget* method, which would mean I have to create a new extension of SelectWidget and then in the MediaSearchWidget constructor, override SearchWidget's constuctor's this.search = new ... assignment... which also then means redoi
[22:43:41] 	 ng the events and the attachment to the dom.
[22:43:47] 	 RoanKattouw: Can you do the rest of the SWATage?
[22:43:49] 	 TrevorParscal, all that ^^ sounds way too complicated for the plan to be sane.
[22:44:00] 	 James_F: Yes
[22:44:11] 	 looking
[22:44:21] 	 RoanKattouw: Thanks!
[22:44:39] 	 TrevorParscal: Wait she's typing more
[22:44:48] 	 ok
[22:44:50] 	 So I am going with another plan, as per Roan's suggestion: I'll ignore my attempts to pre-optimize and instead get it to work with a process that happens *after* addItems runs
[22:44:55] 	 TrevorParscal, ^^
[22:45:06] 	 I was going to suggest the same
[22:45:28] 	 Also, appendItems? isn't that the same as addItems without an index argument?
[22:45:35] 	 3VisualEditor / 3Technical Debt: VisualEditor: Use mw.Api library in mw.Target instead of our own functions - 10https://bugzilla.wikimedia.org/56659 (10James Forrester) 5REOP>3ASSI a:5Rob Moen>3Alex Monk
[22:45:47] 	 ah, yes. I was hoping to not do that because if we end up with 100 search results (which *could* happen, though probably not often) then addItems + reorganize results would go over the 100 items 3 times in 3 loops.
[22:46:05] 	 TrevorParscal, well, i took out only the 'append/prepend' operation from addItem into its own method
[22:46:10] 	 TrevorParscal: Think of it as appendItemElements(), it's just the code that goes this.$group.append()/prepend() and nothing else
[22:46:14] 	 so I can override *only* the actual dom prepend/append operation
[22:46:23] 	 which would have been a decent idea had I not had to recreate half the objects
[22:46:24] 	 But the idea of separating that out is the idea that turned into a mess as she described
[22:46:49] 	 So what I recommended she do is:
[22:47:32] 	 Detach this.$group early on, so the parent class's addItems() will be appending things to a detached container, then right after the parent's addItems() has run, empty that container into the per-line containers
[22:47:33] 	 hmm, I'm not sure I like that being in it's own method
[22:47:42] 	 mostly because addItems already worked that way
[22:47:59] 	 and I don't like there being a lot of methods needing to be supported
[22:48:40] 	 TrevorParscal: Yeah forget about appendItems(), it's essentially an abandoned idea now
[22:49:01] 	 Sorry for the confusion
[22:49:01] 	 ok
[22:49:07] 	 The current idea is the $group thing I mentioned
[22:49:39] 	 Except I overlooked the fact that our customization is in MWMediaSearchWidget which *composes* rather than inherits a GroupElement (SearchResultsWidget by way of SearchWidget, to be exact)
[22:49:49] 	 So it's more like, listen to events and manipulate this.results.$group
[22:49:51] 	 addItems is overriden in the SEarchWidget too, so if I wanted to only override the append process, I had to take some parts of the method from SearchWidget and some from GroupElements into a method overriding addItems
[22:49:58] 	 That reaching in is a bit evil perhaps
[22:50:00] 	 which is why we thought to split apart only that part that deals with append/prepend
[22:50:07] 	 but yes, it's the wrong way to go, at least for now.
[22:50:10] 	 I think you need to decide where the logic for chosing the order of images is going to be
[22:50:24] 	 i get the feeling that is still sort of hand wavy atm
[22:51:00] 	 Well
[22:51:01] 	 It should probably be in the MediaSelectWidget which doesn't exist right now.
[22:51:12] 	 Maybe SearchWidget should allow overriding which class is used for the results widget
[22:51:20] 	 Because MediaSearchWidget composes SearchWidget directly. 
[22:51:22] 	 Right now it's hardcoded as this.results = new OO.ui.SelectWidget
[22:51:27] 	 yeah
[22:51:32] 	 Maybe that should be customizable à la LinkTargetInputWidget
[22:51:49] 	 I feel like GroupElement is a low level system
[22:52:11] 	 and you should avoid adding too much magic to the addItems method
[22:52:24] 	 Right, I'm abandoning that.
[22:52:31] 	 because it ends up biting you later on when you want to access the non-magical portions of the code only
[22:53:11] 	 so, I feel like the "when" do you split them into rows is less interesting than the "how"
[22:53:19] 	 is this going to be a callback of some sort?
[22:53:29] 	 I just need to do things from the widget. The problem is that I have limited access to the SelectWidget (where images are actually 'nested' and displayed) from the MWMediaSearchWidget. I would have overided SelectWidget to a *custom* MWMediaSelectWidget -- but then I can't use it without overriding half the constructor and reattaching this.results 
[22:53:29] 	 like arr.sort( callback ) style?
[22:53:38] 	 Well, the current thinking is this
[22:53:54] 	 We have MWMediaSearchWidget which inherits SearchWidget which manages a result widget for us
[22:54:15] 	 And it uses the GroupElement API (.addItems()/.clearItems()) to communicate with the results widget
[22:54:28] 	 The logic for laying out the images would be in the results widget
[22:54:55] 	 They'd have to be laid out in the order as given to .addItems(), I suppose, but I don't think we're talking about reordering the results, really?
[22:55:05] 	 ok, so you could always have a set of static properties on SearchWidget that specify which query and select widgets to use
[22:55:13] 	 so I don't think that's too hard to do
[22:55:15] 	 Yeah that's what I was thinking
[22:55:19] 	 That part is easy
[22:55:46] 	 sounds like you want to have a MediaResultsWidget
[22:55:57] 	 Yup
[22:56:00] 	 and it is where you handle the ordering and splitting
[22:56:13] 	 Splitting yes
[22:56:22] 	 GroupWidget /could/ have a way to split, by default no splitting is done at all
[22:56:42] 	 There's a MediaResultWidget is the individual oibject -- we need a MediaSelectWidget
[22:56:49] 	 Ordering is irrelevant because we are not even considering changing the order in any way at all
[22:56:56] 	 it could use some sort of mechanism to be able to know which sub-group to place an item into
[22:57:04] 	 (for now)
[22:57:14] 	 mooeypoo: yes, MediaSelectWidget
[22:57:45] 	 Yeah, we can just then need to have a sane way to use it from the MediaSearchWidget
[22:58:00] 	 like what we do with links
[22:58:02] 	 this would cause the group to reevaluate which subgroup every item is in after each change (thank goodness for plural add/remove methods!)
[22:58:29] 	 Well maybe not every item? That seems evil
[22:58:29] 	 add/remove then re-sub-group
[22:58:33] 	 Only added/removed items seems better?
[22:58:57] 	 well, if the item is already in the right place then it need not be moved
[22:59:12] 	 but if you insert an item at the beginning, it would indeed cause a lot of regrouping
[22:59:30] 	 GroupElement should remain generic
[22:59:41] 	 Yeah you're right
[22:59:46] 	 if it's going to support sub-groups, it needs to do so in a reasonably powerful way
[23:00:00] 	 since we are adding items at the end, it won't be a problem
[23:00:27] 	 so, the question is, what information do you need to be able to know which sub-group an item should be in?
[23:00:31] 	 Well, maybe
[23:00:34] 	 But... exactly, that
[23:00:40] 	 How do you know without asking every item every time
[23:00:46] 	 That depends on what you do
[23:00:51] 	 We've had performance problems with large GroupElements in the past and probably still do
[23:00:53] 	 you can either limit groups by number of items (generic?) 
[23:01:10] 	 and then override later in the media stuff to include inside the groups per width
[23:01:13] 	 is it something we can use a callback for, or is it a really messy thing, and we should instead just ask for an array of index moves?
[23:01:14] 	 or accumulated width, etc
[23:01:15] 	 Maybe it should be something where you can ask a group whether it has space?
[23:01:27] 	 A subgroup I mean
[23:01:37] 	 yep that was what I was planning to do
[23:01:54] 	 "how much room is left" sot of thing, where whenever an item is added, you can either query all the groups or just the last group
[23:02:19] 	 Well, you'd start at the insertion position and work your way down
[23:02:26] 	 Right
[23:02:40] 	 the trouble there is that you are building in the concept of horizontal size fitting into GroupElement
[23:02:44] 	 Unless you want to force the insertion position, and then you "push" elements out of the group into another
[23:02:50] 	 Insert at the requested position, ask the group if it's now overfull, if so move it to the next one
[23:02:56] 	 TrevorParscal: No I'm not proposing that exactl
[23:03:20] 	 I'm proposing that the subgroups have a concept of "I do / do not have space for element X" and "I am overfull now"
[23:03:38] 	 "Full" could be defined by width, or number of items, or whatever, that could be handled with inheritance or whatever
[23:03:38] 	 it should support both appending and arbitrary insertion which causes cascading
[23:03:46] 	 Yes
[23:03:53] 	 That's why you need the concept of overfull-ness
[23:04:28] 	 3VisualEditor / 3Data Model: VisualEditor: [Regression]Gallery gets added to the table inside the image - 10https://bugzilla.wikimedia.org/73368#c2 (10etonkovidova) 5UNCO>3NEW In addition to bug 73341 - should tables be allowed for insertion in Media settings?
[23:04:28] 	 do we feel like overflow is the only use case for subgroups?
[23:04:29] 	 Actually I think that's the only concept you really need
[23:04:45] 	 maybe the only sane one?
[23:04:51] 	 Well, if you're going to have magical allocation of which subgroup something goes into...
[23:05:00] 	 Not necessarily though -- if you want -- exactly ^^
[23:05:06] 	 That magic is either going to be "elements that look like X always go into group Y"
[23:05:11] 	 if it's a matter of categorization, for example
[23:05:20] 	 Or it's going to be something that uses a measure of fullness
[23:05:26] 	 Am I missing any other kinds?
[23:05:35] 	 those seem to cover cases I can imagine
[23:05:48] 	 I think it's the only two
[23:05:51] 	 Here's my argument:
[23:05:53] 	 I suppose there could be combinations of both, but I don't know really
[23:05:58] * TrevorParscal listens
[23:06:29] 	 If you have no grouping criteria, then any item can go into any group, so the only thing that can prevent all items from going into one group is if a group is "full"
[23:06:51] 	 So if you do have grouping criteria, you're in case 1, if you don't you're in case 2, therefore there are no other cases
[23:06:58] 	 Hmm, combinations
[23:07:04] 	 You could nest subgroups to achieve that
[23:07:42] 	 So I guess I'm wrong and I haven't covered all cases directly, but any case could be constructed by nesting groupings that fall in one of my two cases
[23:07:54] 	 You can also have a different type of behavior -- "insert into group X" or "insert generally"; the first will insert into group X and cascade if there's no room left, and the second will find a group that has room and insert into that
[23:08:09] 	 Well I don't think that's sane
[23:08:14] 	 You prefer group X but don't require it?
[23:08:23] 	 no I mean you can choose
[23:08:38] 	 I think that the grouping by category may just warrant multiple GroupElement instances
[23:08:40] 	 The mixed cases I'm thinking of is you have groups X1, Y1, X2, Y2, ... and an item must go in one of the Xn
[23:08:48] 	 we don't have that case yet
[23:09:01] 	 but it seems like it will get too dense
[23:09:27] 	 Yeah maybe we should keep it simple
[23:09:31] 	 I was thinking of making this a separate mixin
[23:09:39] 	 Outside of (but using) GroupElemenet
[23:10:03] 	 Then if we need alternative kinds of grouping logic, it's not as big a deal
[23:10:28] 	 so, I was thinking you could not even ask if the sub-group was full, but instead just ask what subgroups should each item be in and then make minimal changes needed to achieve that
[23:10:46] 	 this would be more likely to be optimizable
[23:10:59] 	 Oh you mean something like "which groups are eligible to receive item X?"
[23:11:02] 	 individual item callbacks are always going to be a bottleneck
[23:11:11] 	 And that question could be answered using properties of X, or the sizes of the groups, or both
[23:11:29] 	 no, I mean getAListOfWhichSubgroupsEachItemShouldBeIn()
[23:11:38] 	 Argh
[23:11:48] 	 But that means reevaluating the entire grouping every time
[23:12:03] 	 what you are doing here is adding a 2nd dimension
[23:12:08] 	 I mean yes usually the grouping would be almost the same and you would end up making very few DOM modifications
[23:12:12] 	 when you do that, it makes the calculations more complicated
[23:12:19] 	 But you still have to iterate over every item which I'm trying to avoid
[23:12:43] 	 Where am I adding a 2nd dimension?
[23:12:46] 	 and the only hope you have for optimizing them is caching the few things you can and iterating quickly through data structures and producing a result, then trying to sync it
[23:12:59] 	 it's a 2d array essentially
[23:13:04] 	 row and col
[23:13:16] 	 But I'm never accessing things by col
[23:13:22] 	 It's an array of arrays but that's in the nature of subgroups
[23:13:40] 	 doesn't matter, you have items[row][item] basically
[23:13:44] 	 Yes
[23:13:45] 	 yeah, that's called a 2D array
[23:13:49] 	 But that's the *nature* of subgroups
[23:13:53] 	 of course it is
[23:13:59] 	 I'm not saying *YOU* are doing this
[23:14:03] 	 Oooh OK right
[23:14:06] 	 as if it's a mistake
[23:14:41] 	 So, I still think my fullness thing is simpler and more optimizable than getAListOfWhichSubgroupsEachItemShouldBeIn()
[23:14:51] 	 I'm saying, that it makes things so complex, you will be best served with a sequence( mappingOfCurrentIndexToNewIndex ) method
[23:15:15] 	 and if the sequence has arrays of arrays, it will cause wrapping
[23:15:22] 	 that's one idea
[23:15:50] 	 What I'm saying though, is having to explicitly create and then interpret that sequence every time means throwing a lot of optimization potential out the window
[23:15:51] 	 it's mixing ordering and sub-grouping though - which i don't like
[23:16:03] 	 So my proposal is this:
[23:16:14] 	 When adding an item, add it at the requested index, blindly
[23:16:29] 	 Then figure out which subgroup you just added it to, and ask it if it is now overfull
[23:16:54] 	 I disagree, in my experience it's most common that you will have a variety of partial results that can be reused or paths you can take to short circuit some or all of the processing
[23:16:55] 	 If it is, remove items from its end until it is no longer unhappy, then prepend those items to the next subgroup, ask it if it's unhappy, etc
[23:17:19] 	 OK here is what I feel is the fundamental difference:
[23:17:56] 	 With my proposal, appending an item to the end takes constant time. As in, the time taken to append an item to the end does not depend on how many other items are already in the group
[23:18:03] 	 the trick is to make the "which group is this item in" into a "which group are all items in" because then producing the result has more opportunity for caching and short cuts
[23:18:07] 	 (Except when you break the line but that amortizes)
[23:18:24] 	 But with your proposal, appending an item to the end would take time linear in the number of already existing items
[23:18:33] 	 So as the group grows, appending it would become slower
[23:18:47] 	 with my suggestion, you would notice that the only difference is one new item at the end and reused the same grouping for all other items
[23:18:53] 	 Sure
[23:18:57] 	 s/would/could
[23:19:00] 	 it's about potential
[23:19:01] 	 But you still have to *read* the new grouping
[23:19:23] 	 assuming the new grouping is an exhaustive array instead of a list of changes
[23:19:31] 	 which may only include one item
[23:19:35] 	 Ooh OK
[23:19:45] 	 Generate a list of changes instead of an exhaustive map, now we're talking
[23:19:51] 	 sure
[23:19:55] 	 That's better
[23:20:01] 	 that will be important for the interpretation side for sure
[23:20:11] 	 Yeah because here's the thing
[23:20:23] 	 There is going to be an abstraction barrier between where this information is generated and where it is interpreted
[23:20:25] 	 otherwise that's a full iteration just to check that nothing should be changed in the best performing case
[23:20:30] 	 So the size of this information array matterse
[23:20:52] 	 Because generating an array of N items takes N time, and interpreting it on the other side does too
[23:21:01] 	 agreed
[23:21:08] 	 [18:20]	TrevorParscal	otherwise that's a full iteration just to check that nothing should be changed in the best performing case <---- EXACTLY
[23:21:25] 	 That was my whole point right there, that that full iteration in the best case is unacceptably slow
[23:21:32] 	 I think the trick is to treat the subgrouping as ephemeral, regeneratable from the flat list
[23:21:33] 	 With a list of changes, we can probably do a lot better
[23:21:49] 	 regeneratABLE, sure. RegeneratED, I would object to
[23:21:51] 	 and then only incrimentally change things after an add or remove
[23:22:00] 	 yeah
[23:22:17] 	 i'm just saying, the official order of items shouldn't be shifted away from the items array
[23:22:34] 	 An API like "I want to insert item X at index N, what do you want to actually happen?" would work quite nicely
[23:22:41] 	 Or I guess what you're saying is
[23:22:52] 	 "I just inserted item X at index N, how does this affect the subgroups?"
[23:23:08] 	 And the answer to that question would be an array of statements like "item X1 is now in group G1"
[23:23:22] 	 "I just inserted items X.. at index N, any subgroup changes?
[23:23:29] 	 yes
[23:23:33] 	 Right, items plural, of course
[23:24:00] 	 yeah, and moving items between groups shouldn't change their order - so let's consider an even greater optimization
[23:24:08] 	 the instructions are actually just the break points
[23:24:13] 	 Refer to items by index?
[23:24:15] 	 Oooooh
[23:24:16] 	 not an exhaustive list
[23:24:35] 	 Well, yes and no
[23:24:41] 	 That is not always better
[23:24:55] 	 Let's make it an array of *changes in* break points
[23:25:31] 	 "Group G now starts at index N"
[23:25:35] 	 yes
[23:25:37] 	 exactly
[23:25:46] 	 best of both techniques
[23:25:49] 	 Well
[23:25:59] 	 Maybe, I'm not so sure
[23:26:14] 	 It's suboptimal for insertions in the middle that don't cascade all the way down
[23:26:14] 	 I think it's solid, think it through though
[23:26:27] 	 Because no matter what, the group index changes DO cascade all the way down
[23:26:35] 	 interesting
[23:26:51] 	 But if, worst case, you inserted a tiny item in a not-quite-full group in the middle
[23:26:52] 	 It might fit
[23:26:58] 	 Or it might cascade only once or twice
[23:27:23] 	 (If the insertion point is two rows above a not-quite-full group, say)
[23:28:11] 	 so, if the group index changes (technically) but it doesn't result in any cascading group changes, that means that you make very few DOM changes, so it's just array index translation which isn't very expensive
[23:28:20] 	 That is true
[23:28:29] 	 But I feel like a format that correlates to DOM changes is easier to work with
[23:28:30] 	 the cost of DOM manipulation to cascade an insertion is the scary bit
[23:28:37] 	 maybe it is
[23:29:07] 	 So that's why I think "item X (or item at index K) moves to group Gn" is better
[23:29:20] 	 but I guess defining group offsets, while less simple to translate into DOM changes, does offer a higher level description of what is changing
[23:29:28] 	 Maybe
[23:29:44] 	 Well, I feel like with my API, we don't actually enforce the kind of continuity that yours does
[23:29:49] 	 which I'm just instinctually feeling is good, but maybe it's not
[23:30:01] 	 hmm
[23:30:12] 	 which is your API now?
[23:30:13] 	 lol
[23:30:15] 	 You could have a group that's [1,3,5,7] and another group that's [0,2,4,6]. Whether that's desirable is somewhat questionable, sure
[23:30:19] 	 9 APIs later I'm confused
[23:30:29] 	 But your proposal precludes that
[23:30:49] 	 no, that should never be allowed, the order of items in a group should never be nonlinear in comparison to the items array
[23:30:52] 	 "Your API" = anything to do with group boundaries really, which assumes continuity
[23:31:02] 	 this is why I like the idea of breakpoint indexes
[23:31:04] 	 Right
[23:31:11] 	 It has the benefit of enforcing that model very stronly
[23:31:14] 	 it prevents what you were just saying from being possible to even describe
[23:31:19] 	 yeah
[23:31:37] 	 I noted that my API (I'll define it in a minute) doesn't necessarily enforce that, but I still agree with that model
[23:31:56] 	 the idea is we want to allow normal interactions, like: addItems( someItems, someIndex ), removeItems( someOtherItems )
[23:32:09] 	 and not bother the user with grouping crap
[23:32:18] 	 Yeah that's fair
[23:32:29] 	 and there should be an expectation that the order added is ALWAYS the order displayed
[23:32:57] 	 so, to do that, we do need to enforce continuity between the items array and the item grouping anwyay
[23:33:10] 	 In any case, my proposed API is "items X1, X2, ..., Xn were added at index K, what are the subgroup changes?"  answered with ["Item Xi moves to group Gj", ...]
[23:33:29] 	 The answer will contain the group allocations for the new items, as well as any changes caused by cascading
[23:34:13] 	 right, so you are still describing the changes as moving items between groups
[23:34:18] 	 rather than moving group boundaries
[23:34:43] 	 Yes
[23:34:58] 	 because I feel like moving group boundaries is still sort of nice, in concept, but I will reserve calling it genius until the alternative fails miserably :)
[23:35:42] 	 you could do a lot of the work of cascading with splice
[23:36:07] 	 and we already have efficient array/DOM splice sync code from VE
[23:36:14] 	 ve.ce.BranchNode.onSplice
[23:36:24] 	 so we know that works
[23:36:34] 	 thoguhts?
[23:36:45] 	 I'm totally fine either way, I think both approaches are pretty good
[23:37:17] 	 Roan is fighting with his internet
[23:38:17] 	 Hmm
[23:39:03] 	 OK for some reason my internet connection is acting up here
[23:39:27] 	 (03CR) 10Trevor Parscal: [C: 04-1] "I've talked on IRC about how I feel this isn't a good change, just wanted to make sure it didn't get merged before it could be corrected" [oojs/ui] - 10https://gerrit.wikimedia.org/r/173105 (owner: 10Mooeypoo)
[23:39:39] 	 I think I'm back-ish now
[23:39:40] 	 Anyway
[23:39:47] 	 I do feel like the group boundary thing is clever
[23:39:53] 	 It's probably cleverer than my thing
[23:39:58] 	 I'm just trying to think about how to harness it
[23:40:15] 	 (03CR) 10Trevor Parscal: [C: 032] Add 'indeterminate' state to progress bar widget [oojs/ui] - 10https://gerrit.wikimedia.org/r/171548 (owner: 10Esanders)
[23:40:55] 	 edsanders|away: I'm dissapointed you didn't call your range library "LoneRanger"
[23:41:05] 	 Maybe we could do something interesting like make boundary changes caused by insertions implicit
[23:41:14] 	 https://en.wikipedia.org/wiki/Lone_Ranger
[23:41:41] 	 (When I say "interesting" that usually means "confusing" :P )
[23:41:45] 	 lol
[23:41:46] 	 i know
[23:42:00] 	 So, by default, assume boundary changes follow the insertion
[23:42:09] 	 i.e. everything before the insertion point is +0, everything after is +n
[23:42:09] 	 yeah
[23:42:20] 	 Then specify where the actual boundary changes deviate from that fantasy
[23:43:05] 	 I think, however, that this is still slightly inferior to specifying which items move groups
[23:43:11] 	 did someone review needcheck today?
[23:43:16] 	 https://sv.wikipedia.org/?diff=28659356 - colspan NaN?
[23:43:21] 	 (03Merged) 10jenkins-bot: Add 'indeterminate' state to progress bar widget [oojs/ui] - 10https://gerrit.wikimedia.org/r/171548 (owner: 10Esanders)
[23:43:30] 	 i was thinking insertions would shift boundary indexes, because boundaries are actually defined as an array of lengths and all we did was increase one number
[23:43:39] 	 Because figuring out which item is in which group requires binary search, and would have to be done once on each side of the abstraction barrier for boundary deltas, and only once for group changes
[23:43:52] 	 Aah OK that's celver
[23:43:54] 	 *clever
[23:44:03] 	 again, a ve trick
[23:44:09] 	 Yup
[23:44:46] 	 However, storing lengths instead of absolute offsets makes offset lookup linear instead of logarithmic
[23:44:51] 	 so, if the insertion falls in an existing sub-group (last one for appending, we find which one when specifying an index) and the sub-group is then made longer by the number of items inserted
[23:45:22] 	 [16:33:26] 	 Krenair: BTW, the needcheck bot is running an hour early thanks to DST� :-)
[23:45:22] 	 hmm
[23:45:29] 	 you can then take a pass at fixing it up by asking "now what?" and the result will be some group length changes
[23:45:33] 	 Did I modify the time during the dst changeover week?
[23:45:49] 	 TrevorParscal: Hmm, you could do deltas on the lengths, yes, but that feels like it would be tricky to map it to actual moving around of things
[23:46:02] 	 If your group length changes are [-1, 0, 0, 0, 2]
[23:46:08] 	 then a cascade is described as "make G3 2 items longer"
[23:46:18] 	 which internally cascades
[23:46:33] 	 Then what that means is, your item was inserted in the first group, but then its two last items cascaded into the next, then there were three more 2-item cascades
[23:46:33] 	 set to 17:30 now anyway
[23:46:43] 	 you don't have to say "move this here, move that there, move that to the other place..." exhustively
[23:47:34] 	 RoanKattouw: the idea is that in most cases a cascade will push one item from each group into the next
[23:48:05] 	 but, maybe that's making too many assumptions about how grouping works
[23:48:16] 	 and explicit moves are better for a variety of use cases
[23:48:26] 	 https://pt.wikipedia.org/?diff=40592314 - extra |}?
[23:48:33] 	 implicit moves could be evil if you don't want that "feature"
[23:48:48] 	 colspan=NaN also appeared in https://uk.wikipedia.org/?diff=15130527 and https://ru.wikipedia.org/?diff=66758360
[23:51:11] 	 TrevorParscal: So, on to a completely different topic for a minute
[23:51:17] 	  TrevorParscal So, there's a check icon in the link suggestions that needs to be killed.
[23:51:21] 	 You know how config object extension is wonderful and amazing?
[23:51:26] 	 Right up to the point where you want to unset something :(
[23:51:37] 	 Dammit. I ruined all the fun!
[23:51:55] 	 MWLinkMenuItemWidget (is that its name?) wants to have no icon, but its parent class (MenuItemWidget) sets {icon: 'check'} by default
[23:52:26] 	 sucheta: How dare you ask the question directly instead of tiptoeing around it :P ;)
[23:52:30] 	 yeah, you can't override by using { icon: undefined }
[23:52:36] 	 No you cannot, I tested
[23:52:42] 	 { icon: null } works but feels evil
[23:53:18] 	 Hah, actually...
[23:53:22] 	 if only there were a way to say "JavaScript, i'm defining this as undefined"
[23:53:30] 	 The setIcon() docs say "use null to remove icon"
[23:53:36] 	 yeah
[23:53:40] 	 you can do that
[23:53:51] 	 So I guess { icon: null } is not evil?
[23:53:56] 	 not evil
[23:54:01] 	 it's there for that reason
[23:54:14] 	 null is, in many cases, JavaScript defined undefined
[23:54:14] 	 I just want to you repeat after me "{icon: null} is not evil" before I go off and recommend it to people :)
[23:54:16] 	 OK cool
[23:55:06] 	 sucheta: So yeah, config = $.extend( { icon: null }, config ); should let you get rid of the icon
[23:55:13] 	 I've always felt - perhaps because of my background in system languages - that null should only be used as a bottom value that indicates an object COULD be there but isn't, like an empty parking space
[23:55:32] 	 but we tend to use it for "a string could be here but isn't" as well
[23:55:45] 	 Yeah
[23:55:47] 	 and in JavaScript, strings are and are not objects
[23:55:48] 	 You said this before:
[23:55:57] 	 so, I feel like it's defensable
[23:56:05] 	 "null means 'I know what you mean, but it's not there'; undefined means 'I have no idea what you're talking about' "
[23:56:14] 	 yes
[23:56:16] 	 exactly
[23:56:21] 	 TrevorParscal: As I discovered yesterday, strings are also arrays!
[23:56:36] 	 >>> s = "Hello"; for ( k in s ) { console.log( k, s ); }
[23:56:37] 	 RoanKattouw: undefined; Console: '0', 'Hello', '1', 'Hello', '2', 'Hello', '3', 'Hello', '4', 'Hello'
[23:56:48] 	 Ahm
[23:56:49] 	 >>> s = "Hello"; for ( k in s ) { console.log( k, s[k] ); }
[23:56:49] 	 RoanKattouw: undefined; Console: '0', 'H', '1', 'e', '2', 'l', '3', 'l', '4', 'o'
[23:56:57] 	 yeah, str[0] === str[0][0][0][0] === str.charAt( 0 )
[23:57:04] 	 Yeah
[23:57:07] 	 good fun there
[23:57:09] 	 The str[0][0][0][0] part is especially fun
[23:57:18] 	 You guys :D
[23:57:23] 	 yeah, we abusued this in the ve dm
[23:57:29] 	 as I'm sure you guys all know
[23:57:56] 	 sucheta, I'm sitting here next to Roan while he supertypes
[23:58:01] 	 haha
[23:58:04] 	 data[i][0] works for either "x' or [ "x", { /* annotations */ } ]
[23:58:13] 	 I was attempting to ask a question in between, but I realized the safer method would be to ask *in channel*
[23:58:17] 	 Yeah.
[23:58:38] 	 >>> a = 'x'; b = ['x', ['bold']]; [ a[0], b[0] ];
[23:58:38] 	 RoanKattouw: (object) ['x', 'x']
[23:58:46] 	 Aaanyway
[23:59:00] 	 sucheta: Yeah we are unapologetic JS geeks, as you can probably tell :)
[23:59:02] 	 hoooray for array access on strings!
[23:59:53] 	 mooeypoo, my sympathies