[00:08:13] bd808: If you already have a mobile boarding pass and have no luggage, we can afford to go a little later, perhaps at 6:11pm [00:10:40] the only thing I need to leave time for is my "enhanced patdown" [00:21:54] legoktm, we have a problem with hasMessages() -- it's not invalidating the cache when a new message is sent. I can't figure out why. [00:22:37] legoktm, I was trying to var_dump() stuff in Notification.php where we call 'caceHasMessages()' but it seems to never run...? or at least never run for me in the browser visibly [00:23:24] mooeypoo: it runs deferred, after the output is already sent [00:23:36] legoktm, can't figure out how to debug this. [00:23:41] legoktm, it seems to just not work :( [00:23:54] * legoktm looks [00:24:19] From what I gather, NotifUser "hasMessages" keeps going into the cache condition [00:25:09] So, I start a new user, I get only alerts (so the value 0 is cached)... then from a different user in a different browser, I send the new user a message on their talk page board -- but the new user never gets the message badge. [00:25:18] However, when the new user goes to Special:Notifications the notification is there [00:25:39] so the notification is sent... it just seems to not cache the value 1 [00:25:41] mooeypoo: we haven't merged the move user talk to messages patch yet...or is their talk page a flow board? [00:25:57] the talk page is a flow board [00:26:02] i have all user talk namespace occupied [00:26:12] but this will be the same if the user opts in, too [00:27:14] She's tried it with mentions too [00:27:14] omg [00:27:16] omg I see it [00:27:19] And the messages appear on Special:Notifications [00:27:21] Oh? [00:27:33] THE KEY IS THE WRONG KEY [00:27:38] * mooeypoo mutters [00:27:43] I was caching the wrong key [00:27:58] ... this is like the fourth time I'm using the wrong key when I cache stuff [00:28:03] you would THINK I learn [00:29:09] tried again.... AND NOW IT WORKS [00:29:16] legoktm, thanks! but no need. I am silly. [00:29:22] Let me amuse you with the commit [00:29:50] haha ok [00:30:53] (03PS1) 10Mooeypoo: Use the correct cache key when storing 'hasMessages' [extensions/Echo] - 10https://gerrit.wikimedia.org/r/235945 [00:30:58] RoanKattouw, legoktm, ^^ [00:31:02] * mooeypoo goes to stand in the corner [00:32:57] (03CR) 10Legoktm: [C: 032] Use the correct cache key when storing 'hasMessages' [extensions/Echo] - 10https://gerrit.wikimedia.org/r/235945 (owner: 10Mooeypoo) [00:36:21] legoktm, you know, since I keep making the same mistake here, I think I figured it out [00:36:42] *CLEARLY* my brain has cache which is constantly being invalidated with the wrong key, and hence returns the same wrong value. [00:36:52] legoktm, give me 30 days, I'll stop making this mistake then. [00:37:42] mooeypoo: or we can set you up with an IDE that automatically flags these issues? :) [00:38:14] Sublime does it with javascript, but I didn't set anything up for PHP [00:38:17] I bet there are php linters [00:39:29] (03Merged) 10jenkins-bot: Use the correct cache key when storing 'hasMessages' [extensions/Echo] - 10https://gerrit.wikimedia.org/r/235945 (owner: 10Mooeypoo) [00:41:00] ok, I'm off for the evening. Have a great night, see you tomorrow [00:43:42] see ya :) [04:21:53] (03PS1) 10Purodha: Fix minor typo in message [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235974 [04:34:38] (03PS2) 10Legoktm:
→
in 'flow-notification-enabled-on-talkpage-title-message' [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235974 (owner: 10Purodha) [04:34:47] (03CR) 10Legoktm: [C: 032] "Thanks!" [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235974 (owner: 10Purodha) [04:41:50] (03Merged) 10jenkins-bot:
→
in 'flow-notification-enabled-on-talkpage-title-message' [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235974 (owner: 10Purodha) [06:40:30] 6Collaboration-Team-Backlog, 10Echo, 10MediaWiki-Email: Provide web notifications when user is sent an email via Special:Emailuser - https://phabricator.wikimedia.org/T56130#1605469 (10PerfektesChaos) [07:04:30] 6Collaboration-Team-Backlog, 10Echo, 10MediaWiki-Email: Provide web notifications when user is sent an email via Special:Emailuser - https://phabricator.wikimedia.org/T56130#1605503 (10PerfektesChaos) The new code should be smart and must not trigger an additional echo e-mail which might have been configured... [08:04:43] 6Collaboration-Team-Backlog, 10Flow: BadMethodCallException on history of a Flow page - https://phabricator.wikimedia.org/T111494#1605571 (10He7d3r) 3NEW [10:10:41] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review: Style of new anon edit warning - https://phabricator.wikimedia.org/T110086#1606006 (10Pginer-WMF) >>! In T110086#1604830, @Mooeypoo wrote: > @PGiner-WMF designed per spec, including adding a different message for the submit button for anonymous users. >... [10:51:59] (03PS2) 10Paladox: Use new UserResetAllOptions hook for new users [extensions/Echo] - 10https://gerrit.wikimedia.org/r/145473 (https://bugzilla.wikimedia.org/47895) (owner: 10Legoktm) [10:52:06] (03CR) 10Paladox: "Rebased." [extensions/Echo] - 10https://gerrit.wikimedia.org/r/145473 (https://bugzilla.wikimedia.org/47895) (owner: 10Legoktm) [10:53:58] (03CR) 10Paladox: "Needs rebase." [extensions/Echo] - 10https://gerrit.wikimedia.org/r/63097 (owner: 10Bsitu) [11:01:27] 3Collaboration-Team-Current, 10Flow, 7Database, 7Schema-change, 7WorkType-NewFunctionality: Run "patch-remove_unique_ref_indices.sql" and phase 1 of "Segregate Reference objects by source wiki." on officewiki - https://phabricator.wikimedia.org/T111254#1606167 (10jcrespo) 5Open>3Resolved Resolving be... [11:15:33] 6Collaboration-Team-Backlog, 10Flow, 10MassMessage: Tech News should not use wikitext in topic titles in topics intended for Flow pages - https://phabricator.wikimedia.org/T104914#1606185 (10Aklapper) I'm wondering if T111453 is somehow related. Maybe not. [11:20:05] (03CR) 10Matthias Mullie: Adjust to removal of Connection::getSingleton in Cirrus (031 comment) [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235699 (https://phabricator.wikimedia.org/T111164) (owner: 10Matthias Mullie) [11:20:15] (03PS2) 10Matthias Mullie: Adjust to removal of Connection::getSingleton in Cirrus [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235699 (https://phabricator.wikimedia.org/T111164) [11:22:50] (03CR) 10jenkins-bot: [V: 04-1] Adjust to removal of Connection::getSingleton in Cirrus [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235699 (https://phabricator.wikimedia.org/T111164) (owner: 10Matthias Mullie) [11:36:06] (03PS3) 10Matthias Mullie: Adjust to removal of Connection::getSingleton in Cirrus [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235699 (https://phabricator.wikimedia.org/T111164) [11:38:41] (03CR) 10Matthias Mullie: Adjust to removal of Connection::getSingleton in Cirrus (031 comment) [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235699 (https://phabricator.wikimedia.org/T111164) (owner: 10Matthias Mullie) [12:01:04] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review: Style of new anon edit warning - https://phabricator.wikimedia.org/T110086#1606257 (10Pginer-WMF) I was able to test the patchset: **Grey border:** {F2539792} I noticed a grey border that makes the blue box not to align visually with the text area belo... [12:17:05] (03PS1) 10Sbisson: Browser tests: adjust to actual archive template [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236011 [12:19:58] (03PS1) 10Matthias Mullie: Fix variable capitalization [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236012 [12:44:07] (03PS1) 10Sbisson: Browser tests: Special:EnableFlow without header [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236013 [12:45:02] (03CR) 10Siebrand: [C: 04-1] "i18n/L10n reviewed. Per Roan's comment. Aside from the technical issue, IF you use this way to compute message keys, please add a comment " [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235936 (https://phabricator.wikimedia.org/T110086) (owner: 10Mooeypoo) [12:56:29] (03CR) 10Sbisson: [C: 032] Fix variable capitalization [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236012 (owner: 10Matthias Mullie) [12:58:32] (03Merged) 10jenkins-bot: Fix variable capitalization [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236012 (owner: 10Matthias Mullie) [13:06:20] (03PS1) 10Matthias Mullie: Fix Parsoid conversion when using ParsoidVirtualRESTService [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236015 [13:18:39] (03PS1) 10Matthias Mullie: [WIP] Show real output instead of placeholder HTML [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236016 (https://phabricator.wikimedia.org/T110696) [13:21:04] (03CR) 10jenkins-bot: [V: 04-1] [WIP] Show real output instead of placeholder HTML [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236016 (https://phabricator.wikimedia.org/T110696) (owner: 10Matthias Mullie) [13:25:50] (03CR) 10Matthias Mullie: [C: 04-1] [WIP] Show real output instead of placeholder HTML [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236016 (https://phabricator.wikimedia.org/T110696) (owner: 10Matthias Mullie) [13:40:19] (03CR) 10Sbisson: "Oddly enough, this change was made to allow optin to impersonate "Talk page manager user" without running into Block\Block.php:150 since t" [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236016 (https://phabricator.wikimedia.org/T110696) (owner: 10Matthias Mullie) [14:16:44] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Update Flow'sNomenclature - https://phabricator.wikimedia.org/T111527#1606471 (10Trizek-WMF) 3NEW a:3Trizek-WMF [14:17:00] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a general public documentation for Flow - https://phabricator.wikimedia.org/T111367#1606483 (10Trizek-WMF) [14:17:02] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Update Flow'sNomenclature - https://phabricator.wikimedia.org/T111527#1606471 (10Trizek-WMF) 5Open>3Resolved [14:20:04] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a quick tour about Flow, with most important things to know about - https://phabricator.wikimedia.org/T111528#1606490 (10Trizek-WMF) 3NEW a:3Trizek-WMF [14:20:28] 6Collaboration-Team-Backlog, 10Flow, 7Design: Visual design for new Flow indentation model - https://phabricator.wikimedia.org/T88865#1606498 (10Trizek-WMF) [14:20:30] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a quick tour about Flow, with most important things to know about - https://phabricator.wikimedia.org/T111528#1606490 (10Trizek-WMF) [14:20:47] 6Collaboration-Team-Backlog, 10Flow, 7Design: Visual design for new Flow indentation model - https://phabricator.wikimedia.org/T88865#1021934 (10Trizek-WMF) [14:20:48] 10Collaboration-Team-Sprint-Q-2015-02-25, 10Flow, 5Patch-For-Review: Q1. New model for indentation (French, Catalan) - https://phabricator.wikimedia.org/T88501#1606501 (10Trizek-WMF) [14:20:50] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a general public documentation for Flow - https://phabricator.wikimedia.org/T111367#1606499 (10Trizek-WMF) [14:22:38] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a page about advances settings concerning Flow - https://phabricator.wikimedia.org/T111529#1606503 (10Trizek-WMF) 3NEW a:3Trizek-WMF [14:22:52] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a quick tour about Flow, with most important things to know about - https://phabricator.wikimedia.org/T111528#1606511 (10Trizek-WMF) [14:22:53] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a page about advances settings concerning Flow - https://phabricator.wikimedia.org/T111529#1606503 (10Trizek-WMF) [14:23:59] 6Collaboration-Team-Backlog, 10Flow, 7Documentation: Create a page about advanced settings concerning Flow - https://phabricator.wikimedia.org/T111529#1606503 (10Trizek-WMF) [15:16:34] 6Collaboration-Team-Backlog, 10Flow: BadMethodCallException on history of a Flow page - https://phabricator.wikimedia.org/T111494#1606597 (10Elitre) It's happening for me as well at https://www.mediawiki.org/w/index.php?title=Project:Current_issues&action=history . [16:02:39] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 7WorkType-NewFunctionality: Warn the user if they cancel an editor with data in it - https://phabricator.wikimedia.org/T111115#1606708 (10Etonkovidova) The warning is displayed when 'Cancel' is clicked after editing/adding in either VE or wikitext -... [16:04:02] 6Collaboration-Team-Backlog, 10Flow: BadMethodCallException on history of a Flow page - https://phabricator.wikimedia.org/T111494#1606724 (10Legoktm) ``` 2015-09-04 16:02:05 mw1067 ptwiki exception ERROR: [3ab4f933] /w/index.php?title=Wikip%C3%A9dia:Contato/Fale_com_a_Wikip%C3%A9dia&action=history BadMethodC... [16:04:15] 6Collaboration-Team-Backlog, 10Flow, 7Wikimedia-log-errors: BadMethodCallException on history of a Flow page - https://phabricator.wikimedia.org/T111494#1606726 (10Legoktm) p:5Triage>3High [16:07:50] (03PS23) 10Paladox: Add extension.json, empty PHP entry point [extensions/Echo] - 10https://gerrit.wikimedia.org/r/211298 (https://phabricator.wikimedia.org/T87910) [16:15:42] 6Collaboration-Team-Backlog, 10Flow: Link to Special:Notifications from Alert box does not work for a new user - https://phabricator.wikimedia.org/T111537#1606795 (10Etonkovidova) 3NEW [16:20:19] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 5WMF-deploy-2015-09-08_(1.26wmf22), 7WorkType-Maintenance: Switch Flow to use Parsoid v3 API with VirtualRESTService - https://phabricator.wikimedia.org/T110721#1606810 (10Krenair) Is this done now? [16:42:36] mooeypoo: a question... T111115 Warn the user if they cancel an editor with data in it - you did not use VE Cancel popup? [16:43:11] mooeypoo: in Flow the popup looks different. not sure [16:57:57] etonkovidova, yeah it's not the same popup because it needs to also work with wikitext editor [16:59:15] mooeypoo: I am thinking if it'd be worth to make it visually exactly as VE ... [16:59:20] (03PS17) 10Paladox: Add extension.json, empty PHP entry point [extensions/Flow] - 10https://gerrit.wikimedia.org/r/213837 (https://phabricator.wikimedia.org/T87916) [16:59:27] (03CR) 10jenkins-bot: [V: 04-1] Add extension.json, empty PHP entry point [extensions/Flow] - 10https://gerrit.wikimedia.org/r/213837 (https://phabricator.wikimedia.org/T87916) (owner: 10Paladox) [16:59:48] mooeypoo: maybe I should add two screenshots to the ticket for dannyh to see the difference... [17:01:00] etonkovidova mooeypoo sure, what should I look at? [17:01:07] etonkovidova, I guess so [17:01:18] I could probably make it look the same [17:01:36] dannyh: not just yet :) T111115 - adding screenshots in a min... [17:01:39] dannyh, edit an article with VE, make some change, and then try to leave the page [17:01:54] like... click "back" or your profile page or something [17:02:03] you'll see a confirmation dialog popping up [17:02:18] mooeypoo: nah - maybe it's not worth the effort to make then "exact" [17:02:53] etonkovidova, well, we can't make it exact anyways, because VE's confirmation asks specifically about "Discard / Keep changes" for VE->wikitext [17:03:40] etonkovidova, dannyh when you try to leave the page it pops up an actual alert [17:03:50] like, a browser alert "Navigation confirmation" [17:04:25] etonkovidova, the confirmation dialog you mean happens when you edit in VE without saving, and then click "Edit source" -- then VE asks "Switch to source editing?" [17:04:31] and that uses the same message dialog [17:04:51] etonkovidova, dannyh except the buttons are colored (which I can easily do too if you want) [17:05:26] I'm looking at them... [17:05:37] mooeypoo: nope. in VE - switch to Read mode gives the "same" as in Flow - 'Are you sure?' pop up [17:06:00] That's right, yeah, I forgot about that one. [17:06:11] Well, it looks exactly the same except for the wording and the colored buttons [17:06:21] honestly, it doesn't break my heart [17:06:26] dannyh, I think we looked at it when I asked you for the wording, too [17:06:53] Actually, yes. I copy/pasted the message exactly and just changed "view mode" or something... I am pretty sure. [17:07:10] I think the main difference is the colorful buttons [17:07:25] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 7WorkType-NewFunctionality: Warn the user if they cancel an editor with data in it - https://phabricator.wikimedia.org/T111115#1606970 (10Etonkovidova) Adding two screenshots - VE Cancel popup is slightly different. The browser window size/scale were... [17:08:04] sorry, just thinking about it [17:08:06] :) [17:08:07] oh, the sizing of the font [17:08:09] hmm [17:08:20] dannyh: mooeypoo agree - 'it does not break my heart' either :) [17:08:21] * mooeypoo defers to dannyh and pau on that one :D [17:08:41] making the changes seems pretty straightforward [17:08:42] exactly [17:08:49] etonkovidova, dannyh the good thing about all of this is that since both VE and Flow use OOUI now, the windows are *pretty much* the same [17:09:00] but I have to say, the font size on our buttons is way more readable than theirs [17:09:16] (03PS18) 10Paladox: Add extension.json, empty PHP entry point [extensions/Flow] - 10https://gerrit.wikimedia.org/r/213837 (https://phabricator.wikimedia.org/T87916) [17:09:22] (03CR) 10jenkins-bot: [V: 04-1] Add extension.json, empty PHP entry point [extensions/Flow] - 10https://gerrit.wikimedia.org/r/213837 (https://phabricator.wikimedia.org/T87916) (owner: 10Paladox) [17:09:46] dannyh, i tend to agree, but I don't mind either way [17:10:09] I think add the colors if it's not a big deal, otherwise let it stay as is [17:12:36] (03PS19) 10Paladox: Add extension.json, empty PHP entry point [extensions/Flow] - 10https://gerrit.wikimedia.org/r/213837 (https://phabricator.wikimedia.org/T87916) [17:12:43] (03CR) 10jenkins-bot: [V: 04-1] Add extension.json, empty PHP entry point [extensions/Flow] - 10https://gerrit.wikimedia.org/r/213837 (https://phabricator.wikimedia.org/T87916) (owner: 10Paladox) [17:13:46] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 7WorkType-NewFunctionality: Warn the user if they cancel an editor with data in it - https://phabricator.wikimedia.org/T111115#1606989 (10Mooeypoo) >>! In T111115#1606708, @Etonkovidova wrote: > When the warning is not displayed when > - canceling 'S... [17:14:26] dannyh, we have colors too, I forgot the MessageDialog does it automatically. The difference according to the screenshots is font size, it seems. [17:14:31] anyways, I added my comments on the bug [17:15:29] dannyh, let me know if you want me to add that confirmation to the title edits (see bug comment) [17:16:09] okay, I'll comment on the bug... [17:16:34] (03PS20) 10Paladox: Add extension.json, empty PHP entry point [extensions/Flow] - 10https://gerrit.wikimedia.org/r/213837 (https://phabricator.wikimedia.org/T87916) [17:22:19] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 7WorkType-NewFunctionality: Warn the user if they cancel an editor with data in it - https://phabricator.wikimedia.org/T111115#1607022 (10DannyH) I agree about not popping up the warning just on a title edit. One thing to make sure of is: Add a titl... [17:22:24] mooeypoo okay, commented. [17:22:47] (03CR) 10Mooeypoo: " Okay, you guys are right. I thought I was being all smart about it, but there's really no way for us to actually know what messages" [extensions/Flow] - 10https://gerrit.wikimedia.org/r/235936 (https://phabricator.wikimedia.org/T110086) (owner: 10Mooeypoo) [17:24:13] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 7WorkType-NewFunctionality: Warn the user if they cancel an editor with data in it - https://phabricator.wikimedia.org/T111115#1607037 (10Mooeypoo) >>! In T111115#1607022, @DannyH wrote: > I agree about not popping up the warning just on a title edit.... [17:34:09] stephanebisson legoktm standup ping? [17:39:43] 3Collaboration-Team-Current, 10Flow, 7Schema-change, 7WorkType-NewFunctionality: Do backfill and final schema change for "Segregate Reference objects by source wiki." - https://phabricator.wikimedia.org/T111084#1607136 (10DannyH) p:5Triage>3High [18:01:01] mooeypoo: can you tell me again what's the job of the DM, what does it DO? [18:03:29] stephanebisson, the DM holds and deals with the actual data level of the board. It stores the data, updates it properly when needed, and handles the operations of interconnected pieces so that the widgets can just always stay updated. It's like a view-model. [18:04:47] mooeypoo: it uses the API to execute the operations and stay up-to-date? [18:04:58] It accepts the board data when we initialize and fills up the different data models - the description, the board topics, etc. Each widget can then latch onto whatever data model piece is relevant to it and make sure it is always in sync with the actual state of the data. [18:05:13] stephanebisson, yes. And widgets trigger operations in it. [18:05:50] stephanebisson, the ideal would've been that the data model is the entire underlying level of data [18:06:26] but the old system makes it hard ... so right now it's a bit of a partial manager trying to live with the old system. That's why we have a lot of stuff in flow-initialize [18:06:50] I can see that ;) [18:07:06] And we have some hacks in dm.System that are technically not really proper, but had to be there to make sense of the half-new half-old state [18:07:31] Yeah, we couldn't redo the entire system, so since we did things incrementally, we had to still do things with the old system in place. [18:07:33] so the api usage is hidden behind domain level operations executed by the DM [18:08:14] so widgets trigger operations on DM, like: postObj.edit ( newContent, newFormat ) [18:08:16] No, the API is called by the widgets [18:08:34] 6Collaboration-Team-Backlog, 10Flow, 7Wikimedia-log-errors: BadMethodCallException on history of a Flow page - https://phabricator.wikimedia.org/T111494#1607900 (10Rical) In Firebug, below the content div, I see
with the attribute width:100%; If I modify to width:50%;... [18:08:52] then the DM does not do operations... [18:09:05] the widgets do operations on the API [18:09:07] The DM does operations on the data it *has*. [18:09:30] Yes, the DM is "dumb" in that sense. [18:09:41] that's where I'm lost [18:09:43] It holds the data and knows the relationships between properties and objects inside it [18:10:19] The DM doesn't know or care about anything external to it. You give it data, it organizes it, it lets you know when something is changed. If you change a property that requires multiple other property changes, it does that for you, and make sure everything is synchronized. [18:10:56] But if you want to completely replace something, say, the content of the description -- you do that externally. That also makes sense,because htat's done by the user, who interacts with a widget. [18:11:01] as a widget, you are responsible for calling the api, gettting new data, and storing it in the DM? [18:11:08] Yes [18:11:13] And listening to the DM for changes [18:11:17] the DM is your engine [18:11:25] I listen to it for any chance and react, and I dump my new data into it [18:11:34] in what way is it your engine? [18:11:43] it doesn't do anything [18:12:01] it fires events back to the component is charge of setting it's data [18:12:56] I can imagine the DM being the datatypes interface of the API, or the other way around, the DM exposing operations that it executes with the API [18:13:20] but the current state... I'm missing something [18:13:23] Yes, no, you're right, bad analogy (which is probably why I don't drive much) == I meant in the sense that the widget's properties should always be aligned with the DM. But when it does something active like fetching or updating the API, it "dumps" the response on the DM and waits for *the dm* to tell it what to do. [18:14:39] Updating one piece might result in changing another. The widgets trust the DM to be their common link and "synchronizer". [18:15:03] All data goes to the DM who, blindly, knows what to do with the data ,where to put it, what events to emit, etc. [18:15:11] The widgets listen to those events and respond. [18:15:21] Does this make more sense? I am not sure I am explaining myself fully. [18:16:35] I think I get how it works [18:16:56] I'm trying to come up with a good analogy to what the DM is, and visual analogies fail me. [18:17:48] analogies always fall short [18:17:55] Also, I clearly should learn more about car engines.... ;) [18:18:53] The entire purpose of the DM is to make sure everything is synchronized. You don't want the widget to respond to its own operations because then you risk a situation where your data (in the api, or in the representation on the document) is different than what the widget holds. [18:19:49] You want one layer that deals with synchronizing and updating the data and make sure all your widgets listen to *it*. So no matter what the widget shows, you know it represents the actual current data and not some mishap response it *thought* it should have because of an internal representation. That makes sense? [18:20:14] it does [18:20:34] you are describing the benefits of the Flux architecture [18:20:56] Flux architecture... I've never heard of that... [18:21:00] I'll check it out [18:21:07] commands up, data down [18:21:40] the UI (widgets) issue commands to a store and listen to data change events on that same store [18:21:47] yeah, exactly [18:22:13] It's the same architecture VE uses too [18:22:17] the store keeps the data consistent by executing api calls and updating it's internal representation as needed [18:22:27] Although in VE the data model is a lot more complex. [18:22:28] that's not what we have [18:22:54] No, the DM is stupid and doesn't know anything about the UI [18:23:01] the UI knows about the DM and updates it. [18:23:17] the DM just knows about itself and rearranges the data accordingly, emitting events as neded. [18:23:35] this logic is typically put in a controller, not in the UI [18:24:39] I saw either. I actually think creating a controller in between DM and UI can make things even more complicated in some cases [18:24:55] and in our case, especially with the old system to work with, that seemed to me to be complicating things [18:25:25] we have flow-initialize stuff that bridge between the old system and the new and half of our stuff are not widgetized yet. I tought having another layer would just complicate things even worse. [18:28:33] anyway, now I understand how it's supposed to work, thanks [18:28:36] One part I'm not clear on is why the client-side API (mw.flow.dm.APIHandler) (part of the data model) doesn't update the data model internal state with the response itself (e.g. saveReply doesn't update the topic) [18:30:07] The API Handler is not entirely part of the DM. It's called dm.APIHanlder because it is dealing with data, but it's more of a helper [18:30:50] It's just there to give us the correct api methods. Putting dm changes in it will limit the uses of the functions in it [18:30:52] it's the closest thing we have to a controller (not in the MVC sense) since it creates a half-nice interface [18:31:16] yeah, i was going to say, it's a little closer to a controller, though more of a helper. [18:31:34] mooeypoo, when would you need to save a reply without the data model being aware of the new reply? [18:31:35] It's supposed to be an easier interface to the api methods for reuse [18:32:31] It's not about whether or not you would (you're right, you probably wouldn't) i's about what should actually do it [18:32:43] 3Collaboration-Team-Current, 10Beta-Cluster, 7WorkType-Maintenance: update.php broken in Beta - https://phabricator.wikimedia.org/T111267#1609068 (10Mattflaschen) a:3Mattflaschen [18:32:55] It made more sense to have the API be an interface-only thing, and whatever did the actual request make sure the model is updated. [18:33:05] We can rethink this, though, if you think that's wrong. [18:34:14] It was more about abstraction of operation and keeping the logic in "logical" places (?) .. have the APIHandler simplify the api calls and keep track of api-specific things, and have whatever call it deal with (a) the data returned and (b) errors if those happen [18:34:30] I'm not necessarily saying we should redo it, I just think that would be an alternative (maybe simpler) way to do it. But I could be missing the downside. [18:35:01] But the API handler could update its DM on success while still informing the caller of failure details through the promise, so they could be handled. [18:35:11] I think making the api nicer client-side by wrapping it is a no-brainer, especially for our api [18:35:36] but having the widget update the model after it doesn't make sense to me [18:36:10] I think it's more organized for the widget to follow up and do the updating, since there might be mor ethan one update the widget needs to do [18:36:31] but i can see the benefit in making widgets less data-logic-driven [18:36:40] 6Collaboration-Team-Backlog, 10Flow, 10MediaWiki-extensions-MultimediaViewer, 6Multimedia: Media Viewer doesn't trigger on Flow-enabled talk pages - https://phabricator.wikimedia.org/T64594#1609347 (10Jdforrester-WMF) [18:36:52] (03PS2) 10Legoktm: build: Bump grunt-contrib-jshint from 0.11.2 to 0.11.3 to fix upstream issue [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/235886 (owner: 10Jforrester) [18:36:53] the widget already has the data, it's putting it there for the benefits or others [18:37:23] the sync depends on the good-will of widgets [18:37:27] Not necessarily. The description is a good example -- the widget MUST query the API to be able to display the data, because the data it has from the editor is in the wrong format [18:38:25] it's a good example, what's the point of the DM here? [18:38:33] (03CR) 10jenkins-bot: [V: 04-1] build: Bump grunt-contrib-jshint from 0.11.2 to 0.11.3 to fix upstream issue [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/235886 (owner: 10Jforrester) [18:39:24] Yeah, that one I am also not happy with. The dm still has a point in updating othre data in there, but I am very unhappy with the way it works right now, considering the widget must fetch from the API to display anyways [18:40:18] Also there's an issue about the updating of content vs contentFormat. The relationship between those two is problematic to widget. If one changes, the other probably changed too anyways. Or maybe not. But then, the widget can't display it anyways, so it needs to fetch from the API... [18:40:33] but yes. That bit is messy and crappy. We should definitely rethink the description. [18:41:34] The whole idea of the DM was to have something to synchronize all the widgets on, and "not care" where the data comes from. So, theoretically, you could also have "push" data where suddenly replies are being added to a topic [18:42:16] mooeypoo: I like this idea [18:42:34] Because the DM doesn't care where the data comes from, and maybe it should -- or maybe it shouldn't. Theoretically in that scenario, you could have a gadget add stuff to the DM that is not in the API. [18:42:56] is that a good thing? I'm not sure. I think it might be for certain cases. [18:43:09] 6Collaboration-Team-Backlog, 10Echo, 10Flow: Improve organization and control for Flow notifications (tracking + ideas) - https://phabricator.wikimedia.org/T100528#1609689 (10ggellerman) [18:43:14] But you see my point... the purpose of the DM is to be the common layer there [18:43:53] 6Collaboration-Team-Backlog, 10Echo, 10Flow: Improve organization and control for Flow notifications (tracking + ideas) - https://phabricator.wikimedia.org/T100528#1314884 (10ggellerman) Removing Design Research project. Please feel free to re-add if work on this task resumes. [18:44:12] I agree with the intentions [18:44:36] there are good architectural patterns out there to achieve it and we depart from them in a weird way [18:45:04] stephanebisson, yeah, no, I agree that the *actual* architecture turned out quite weird. Some of it was because of the incremental-building [18:45:25] some was because of the old system, and some was because we needed to adjust to existing things in the API [18:45:28] it muddies the water quite a bit [18:45:42] But yeah, we could rething some (or a lot) of the implementation [18:46:08] If you have notes about these, we should follow up (or create a task for future reference if we can't do it in this quarter) [19:10:49] (03PS1) 10Mattflaschen: Add debugging code for invalid titles in WikiReference [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236071 (https://phabricator.wikimedia.org/T111267) [19:11:13] https://gerrit.wikimedia.org/r/#/c/236071/ will help me debug the Beta problem. [19:13:37] (03CR) 10Sbisson: [C: 032] Add debugging code for invalid titles in WikiReference [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236071 (https://phabricator.wikimedia.org/T111267) (owner: 10Mattflaschen) [19:13:43] there you go sir [19:13:55] Thanks. :) [19:17:33] (03Merged) 10jenkins-bot: Add debugging code for invalid titles in WikiReference [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236071 (https://phabricator.wikimedia.org/T111267) (owner: 10Mattflaschen) [19:22:17] 6Collaboration-Team-Backlog, 10Flow: Flow: Prettify thread permalink URLs/Titles (they are not human readable!) - https://phabricator.wikimedia.org/T59154#1610369 (10xcombelle) A possibility would be [[Flow:/original-title]] would be the canonical link to a flow discussion, which if the discussion is... [19:28:44] meh. matt_flaschen I'm going over the test failure, but I'm running into a REALLY weird error in the Special:JavaScriptTest/qunit in general. When I run it, I get (intermittently, but most of the time) an exception in "mediaWiki.template.registerCompiler( 'regexp', {" with "Uncaught TypeError: Cannot read property 'registerCompiler' of undefined" [19:28:48] do you have *any* idea what this is from? [19:29:38] registerCompiler( 'regexp' )... that's a new one. The only ones I knew about were Handlebars, Hogan, and I think static HTML. [19:30:36] It seems to stem from mediawiki.Uri.js [19:30:47] strict: mw.template.get( 'mediawiki.Uri', 'strict.regexp' ).render(), [19:30:52] https://github.com/wikimedia/mediawiki/commit/225719993a7b355dbfde5f0a49e6f161d6f75e41 [19:31:17] bah [19:31:26] MatmaRex, ? [19:31:50] Looks like a missing dependency. [19:31:57] hey [19:31:58] hmmm [19:32:00] Uncaught TypeError: Cannot read property 'registerCompiler' of undefined(anonymous function) @ mediawiki.template.regexp.js:1 [19:32:01] mediawiki.template.js:47 Uncaught Error: Unknown compiler regexpmw.template.getCompiler @ mediawiki.template.js:47mw.template.compile @ mediawiki.template.js:108mw.template.add @ mediawiki.template.js:70mw.template.get @ mediawiki.template.js:93(anonymous function) @ mediawiki.Uri.js:86(anonymous function) @ mediawiki.Uri.js:422 [19:32:01] ve.init.mw.DesktopArticleTarget.init.js:201 Uncaught TypeError: mw.Uri is not a function(anonymous function) @ ve.init.mw.DesktopArticleTarget.init.js:201(anonymous function) @ ve.init.mw.DesktopArticleTarget.init.js:628 [19:34:18] MatmaRex, maybe mediawiki.template.regexp needs to depend on mediawiki.template? ... But why wasn't this an issue before for mediawiki.template.mustache, etc.? [19:34:27] mooeypoo: hmmm. yeah, mediawiki.template.regexp looks like it should depend on mediawiki.template. i wonder why this was never a problem for mediawiki.template.mustache, though. [19:34:34] hah [19:34:35] ha [19:34:51] Who uses mustache [19:35:33] mobile, i guess [19:35:38] It didn't break on regular pages for me. could it be we just didn't notice? [19:36:00] maybe some of the recent tweaks to resourceloader caused things to be ordered differently [19:36:11] anyway. adding the dependency seems like a sane thing to do [19:36:26] Yeah, I'll go ahead and add both of them. Shouldn't break anything... [19:37:03] awesomesauce [19:37:05] thanks ! [19:37:34] (if you're curious, mw.template.regexp is a lame/clever hack for JavaScript's lack of multiline regexps :) ) [19:38:51] Yeah I was just going over it [19:38:59] MatmaRex, and named groups, it said? [19:39:05] I am still trying to wrap my head around mediawiki.ui.enhanced though [19:39:16] mooeypoo, https://gerrit.wikimedia.org/r/#/c/236079/ [19:39:51] \o/ [19:40:28] matt_flaschen: yeah, but they're more like comments. comments are more difficult to implement because i'd actually have to handle backslash-escaping, while this is unlikely to conflict with real-world use cases [19:47:15] meh, it's still failing for me [19:47:24] I just finished doing vagrant git-update [19:47:31] it shouldn't fail... [19:48:05] * mooeypoo restarts chrome [19:50:25] ah, now it works [19:50:46] 3Collaboration-Team-Current, 10Beta-Cluster, 5Patch-For-Review, 7WorkType-Maintenance: update.php broken in Beta - https://phabricator.wikimedia.org/T111267#1610463 (10Mattflaschen) ``` 2015-09-04 19:26:30 deployment-bastion enwiki Flow INFO: Flow\Model\WikiReference::makeTitle: Invalid title. Namespace:... [19:52:39] oy. matt_flaschen, the intermittently-failing test uses the old editor system. I have a feeling that's why it fails [19:53:15] mooeypoo, I don't remember seeing this bug before, but I could be wrong. [19:53:22] stephanebisson: https://phabricator.wikimedia.org/T98270- Opt-in for Flow on your own user talk page. Switching Flow OFF does not work for me :( [19:53:54] matt_flaschen, I can't reproduce the failures at all, which makes this really hard to debug, so I'm assuming for now until I can reproduce. I'm trying to come up with failable scenarios [19:54:18] etonkovidova: unfortunately there is no user feedback. Do you have access to the exception log on beta? [19:54:50] stephanebisson: hmm... never looked there [19:55:00] stephanebisson: it's on bastion? [19:55:07] etonkovidova: no idea [19:55:36] but I would like to know where to look [19:55:50] etonkovidova, stephanebisson you can use either http://logstash-beta.wmflabs.org/ (nice-looking interface, but takes some getting used to) or deployment-fluorine (good ol' files and grep) [19:56:15] I'm not sure if absolutely everything in the files is in logstash. [19:56:38] Files on deployment-fluorine are in /a/mw-log/ [19:56:47] it would be nice to know right away when people are using opt-in and it fails [19:56:49] stephanebisson: I duly turned "Flow on user talk" OFF - i.e. unchecked the check box - and I still see and use the User talk: Flow board [19:56:58] wow, I'm getting the registerCompiler failures again [19:57:00] it *just* worked [19:57:30] Double-check fix is include in your commit of MW and clear cache? [19:58:17] yeah I pulled from mw and opened a brand new tab and hard-refreshed. It worked once, then again triggered the error. I just opened a new tab again, so far so good. [19:58:19] weird. [19:58:21] 3Collaboration-Team-Current, 10Beta-Cluster, 5Patch-For-Review, 7WorkType-Maintenance: update.php broken in Beta - https://phabricator.wikimedia.org/T111267#1610475 (10Mattflaschen) Title::makeTitleSafe fails, but Title::makeTitle returns a Title. This is because MWNamespace::exists( 100 ) is false (there... [20:03:10] matt_flaschen: thanks for the info! Looking... [20:03:59] stephanebisson: so opting-out is supposed to work as it's described in the ticket? No other interpretations? :) [20:04:57] etonkovidova: yes, it should just work [20:05:17] stephanebisson: argh... [20:05:30] etonkovidova: but the process is complex and I'm not surprised it doesn't always work [20:06:08] I need to be able to find the logs for that [20:06:41] stephanebisson: for me it does not work at all :( Looking in the logs too... [20:06:51] this is what we have: MWExceptionHandler::logException( $e ); [20:07:11] we need to change it so we can easily find it [20:07:17] I find the main ones on (deployment-)fluorine are hhvm.log, fatal.log, exception.log, and Flow.log [20:07:56] matt_flaschen: how to look at exception.log in logstash? [20:08:09] In this case, I used deployment-fluorine. [20:08:28] I'll see if it's also in logtstash for reference. [20:08:29] mattflaschen@deployment-fluorine:~$ tail -n 100 /a/mw-log/exception.log [20:09:12] "type:mediawiki AND channel:exception" [20:09:22] https://logstash-beta.wmflabs.org/#dashboard/temp/AU-Z-kJoa1EjumVdGaUf [20:09:28] matt_flaschen: how can we modify `MWExceptionHandler::logException( $e );` to be explicit about the fact that this is an opt-in/out failure? [20:09:52] stephanebisson: matt_flaschenyeah, I see stuff like -- Could not locate workflow for 127519 {"exception":"[Exception Flow\\Exception\\FlowException] [20:10:13] that can be it [20:10:54] stephanebisson: it's just at tail /a/mw-log/exception.log [20:11:12] (interesting that people are trying to access /etc/passwd) [20:16:08] stephanebisson, FlowException has a custom message, so you could catch and rethrow. Also, it's in the trace. [20:16:08] stephanebisson, https://phabricator.wikimedia.org/P1986 [20:16:08] stephanebisson, I believe they're doing security scanning on Beta now (I don't know the details, but I heard about it in SoS). Looks like it might be fuzzing from that (or a genuine attacker). [20:16:08] bd808, thanks, but I can't seem to find it: https://logstash-beta.wmflabs.org/#/dashboard/temp/AU-Z-kJoa1EjumVdGaUf I'm looking to find https://phabricator.wikimedia.org/P1986 . [20:16:09] I think I'm going to add Flow_test and Flow_test_talk to all the Beta wikis. [20:16:10] When we enabled it on enwiki and cawiki, we accidentally disabled all the normal custom namespaces inherited from production. [20:16:44] These previously existed, so now there are abandoned links table entries causing the Beta problem. There is a way to add custom namespaces only on Beta using +beta, but it looks like it might have to apply to all Beta sites. [20:17:49] matt_flaschen, i *again* have issues with the module, but this time it happened after I set debug=true [20:18:01] could this be an issue with debug mode, or maybe some annoying cache for vagrant or something? [20:18:16] mooeypoo, still the registerCompiler? [20:18:17] I just *restarted* my entire computer because chrome crashed and i didn't trust it to show me valid status [20:18:18] yeah [20:18:38] mooeypoo, I know you did hard refresh, but did you actually clear your browser cache? [20:18:43] it was all good, but then I ran the test with debug=true to look at my debugger statements, and poof -- the registerCompiler failed again [20:19:03] I shift-refreshed which is supposed to hard-refresh without cache, but let me actually clear stuff. [20:19:12] wait [20:19:13] wait wait [20:19:22] ok, now it works [20:19:47] i cleared cache and refreshed, and there was again an exception -- but this time it was something from MobileFrontend [20:19:51] and it didn't crash anything [20:20:01] Hopefully it sticks this time. [20:20:04] * mooeypoo nods [20:20:06] seriously. [20:20:27] matt_flaschen, I also confirmed that the error we get is the timer issue [20:20:45] matt_flaschen: hmm.. that really should be showing up in logstash but I agree that its not there [20:20:47] I can't reproduce it with the timer, but it fails when i either remove the 'clock' statement or make it small. [20:22:05] mooeypoo, hmm, I see that's already using fake timers. [20:22:13] yeah [20:22:22] when I remove the fake timer the tests fail [20:22:30] but when they're there, I can't reproduce the failure [20:22:43] mooeypoo: what is the test testing? [20:23:10] We're apparently setting submit button to disabled under certain circumstances (like the editor not being available) [20:23:17] only, we're doing it in a really... weird... way. [20:23:41] sounds like old stuff that should be clean up [20:23:46] cleaned up [20:23:48] I looked through the code to see how much we're still using it, and we still are :( [20:24:01] stephanebisson, that's what I thought at first, but we still have a number of places where this is used [20:24:04] (03CR) 10Cscott: [C: 04-2] "This shouldn't be the case. For the Parsoid v3 API, which the latest ParsoidVirtualRestService in core uses, both Parsoid and RESTBase sh" [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236015 (owner: 10Matthias Mullie) [20:24:08] I'm worried about clearing it [20:24:56] Eh. [20:25:11] I would've taken the entire thing out, but we will probably lose some functionality of disabling buttons and blurring stuff. [20:25:27] mooeypoo: is it worth simplifying the tests? (i.e.. trying to break the dependencies rather than satisfying them) [20:26:02] the test is fairly simple [20:26:16] The operation itself doesn't work in time, though, it seems [20:26:22] it's the setTimeout() fault, imho [20:26:34] i can see how this can fail in cases where other thingshave stuff that change things in the stack [20:26:44] but the setTimeout seems to be necessary for paste [20:28:53] If I remove the setTimeout the tests pass. [20:29:13] but according to the documentation, setTimeout() is there to make sure the method is running after paste event if it's fired. [20:29:18] * mooeypoo grunts [20:29:25] this whole script is messy as hell [20:41:44] mooeypoo, you can test and see if it's still necessary, but I wrote that comment and I would guess it still is. [20:41:55] mooeypoo, it's not for the editor not being available. It's just for when you don't have anything in the textbox. [20:42:01] So you have a blank textbox and the button is disabled. [20:42:07] Then you paste something in, and it should enable. [20:44:37] I pinged Krinkle. It seems like a straight-forward fake timer use case, and I'm not sure why it's started causing problems. [20:44:42] matt_flaschen, yeha, I saw that it's testing whether there's stuff in the editor along with whether the editor exists. The issue is with the pasting [20:44:54] it seems the setTimeout needs to be there for it to work right [20:45:04] Yeah [20:45:06] but that causes the test to occasionally break :\ [20:45:22] mooeypoo, however the test does not test paste. So if we're really stuck, we can implement two separate listeners, and only do the setTimeout for paste. [20:45:26] I was trying to see how VE does pasting, but they use a whole system with their internal model, it's incompatible [20:45:35] Which means the test won't have to worry about it since it only tests keyup. [20:45:53] hm [20:46:03] But it should be fine. We set a setTimeout of unspecified time (which I believe is ~4 ms), then fake time ahead 1 second. [20:46:32] yeah it should be. The tests work for me even if we fake time ahead 10 milliseconds [20:46:38] but apparently it fails for other extensions [20:46:45] I'm not sure here. [20:46:56] ah, speak of the Krinkle :) [20:47:03] 6Collaboration-Team-Backlog, 3Collaboration-Team-Current, 10Flow: Flaky test "ext.flow: mediawiki.ui.enhance Forms with required fields" - https://phabricator.wikimedia.org/T111459#1610573 (10Mattflaschen) [20:47:09] * Krinkle reads back log [20:48:41] Okay [20:49:29] Hmm, it doesn't test that it enables, only that it disables on the event. [20:52:12] yeah only disables. It works consistently for my tests. I can't manage to trigger a failure, so I can't see what causes it -- my guess is that maybe we have something in between the 4ms and 1second that changes things? I can't imagine what, though. We're creating our own fake encapsulated forms that shouldn't be touched by anything [20:52:27] no event would be triggered on those forms to change the output of that test. [20:52:31] It's baffling to me. [20:53:25] e4c8a1504fe99e60ab8c452e644f97e53a887b65 doesn't look problematic, though it is relatively recent and touches this code. [20:56:51] Can you link to the code this is about? [20:57:08] mooeypoo: I still cannot not see "Opt-in: Guided tour on user talk for first visit to new Flow board" in beta - for any kind of users ... :( [20:57:33] mooeypoo: The conversation about setTimeout and paste, is that about https://phabricator.wikimedia.org/T111459 ? [20:58:40] etonkovidova, meh [20:58:53] Krinkle, yes [20:59:11] Krinkle, the test that fails has fake timer in it [20:59:14] mooeypoo: right... nothing works on my machine today [20:59:26] mooeypoo: ah, the fake timer is already there? [20:59:29] Krinkle, "this.clock.tick( 1000 );" [20:59:56] ^^ that's in the test [21:00:04] the method it tests has a setTimeout( ... ) [21:00:16] the setTimeout is there for pasting [21:01:11] Code: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FFlow.git/321409f0370f4f99e19a136f6a1fbc8f93c198b3/modules%2Fengine%2Fmisc%2Fmw-ui.enhance.js#L118 [21:01:27] Ah, I was going to do the same [21:01:54] Test: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FFlow.git/321409f0370f4f99e19a136f6a1fbc8f93c198b3/tests%2Fqunit%2Fengine%2Fmisc%2Ftest_mw-ui.enhance.js#L1 [21:02:12] And this is the te-- yes. [21:02:20] * mooeypoo isn't fast enough [21:22:45] mooeypoo: OK. So have you identified the problem and a solution? [21:23:07] Maybe it's that there is a nested setTimeout, so a single tick() would only flush the first burst, not the ones added by that burst. [21:25:08] We identified the problem, not a solution [21:25:16] we are also not entirely sure we understand why he problem is a problem at all [21:25:29] Okay. tell me about your problems ;-) [21:26:41] * mooeypoo lies back on the couch [21:26:52] * Krinkle puts on glasses [21:27:00] Krinkle, where is it nested? I see how at runtime it would be parallel (multiple triggers in the test roughly the same time), but they should all be passed over by 1000 ms. [21:27:11] :) [21:27:40] Krinkle, seriously, though -- the method has a setTimeout() that seems to be required to operate properly with paste operations, so we need it. The tests, before we compare results, fake 1000ms tick. [21:27:48] I don't understand why anything would interfere with that. [21:27:52] tick(1000) doesn't let 1000ms of reality pass by. It looks in the timeout queue and runs anything scheduled for <= 1000ms in the future. [21:27:54] We set up our own $form to test with [21:28:00] once [21:28:24] which will trigger multiple functions (not just one) but it will only pass through once [21:28:49] in this case, keyup is fired a bunch of times, scheduling timeouts [21:28:50] and then you run them [21:28:53] that looks fine [21:29:05] matt_flaschen: I don't see a nested timeout (yet), it was a suspicion [21:29:11] Oh, okay. [21:29:47] Even if we have a whole bunch of events that fired the setTimeout() function, they are all under 1000ms [21:29:53] Also, this is not new code mostly, but e4c8a1504fe99e60ab8c452e644f97e53a887b65 is new. [21:29:56] wouldn't that mean they are all going before the tests? [21:30:32] mooeypoo, and it should be roughly in parallel anyway. It doesn't wait 4 ms before the next trigger. [21:31:14] Yeah, and that shouldn't cause any failures, either. [21:31:28] This whole thing is baffling. I don't understand why these tests would fail -- let alone intermittently [21:31:44] what do you mean by paralllel? [21:31:52] I changed my mind, and just added the namespaces from prod to the labs version. I didn't want to enable the Flow_test_talk on wikis where we don't have Flow, and it didn't seem like +beta allowed that control. [21:32:01] So https://gerrit.wikimedia.org/r/#/c/236206/ [21:32:21] Krinkle, not literally parallel. I just mean that it doesn't wait for the setTimeout to complete before triggering a new keyup. [21:32:28] Right [21:32:59] So any prep work that may happen before the setTimeout will happen out of order (e.g. 5x prep, then 5x timeout callback) [21:33:48] Anyway, I can't help but notice this tests is kind of written the wrong way. I get that it's determining some logic through what happens when elements are required. [21:33:53] Is there not a more direct way to test that? [21:34:07] It's not appropiate to test whether trigger() triggers the on() callback, that's jQuerys job. [21:34:33] take extenral event handlers for granted, reduce event handlers to handling event and calling actual methods and test those methods. [21:35:12] Yeah we can probably just test the method directly [21:35:31] As an experiment, perhaps move the tick to inside the each() [21:35:48] and run it twice, just in case. That'll help narrow down the problem if that makes it go away. [21:36:04] can you reproduce it locally (after running it enough times)? [21:36:11] * mooeypoo tries something [21:36:20] no I couldn't reproduce the failures [21:36:43] but now that you're saying this, I don't think we need to trigger any keyup at all. The trigger keyup causes enableFormWithRequiredFields() to run on the form [21:36:51] so why not just run enableFormWithRequiredFields() on the forms directly [21:37:08] that's a good start yeah [21:37:37] We'll be skipping any and all need for ticks and fake timeouts [21:37:58] Hm.. another thing to check out (assuming https://gerrit.wikimedia.org/r/#/c/216679/6/modules/engine/misc/mw-ui.enhance.js is related) - maybe something is getting triggered multiple times due to the extra selector? [21:38:07] That might cancel thigns out if it includes part of a form twice [21:38:23] just a guess [21:38:53] Krinkle, could be, but at first glance those should be disjoint. OO UI shouldn't be using mw-ui-input, and an element can't be both input and textarea. [21:39:06] eh [21:39:19] calling enableFormWithRequiredFields() from the test means I need to expose enableFormWithRequiredFields() outside of its file. [21:39:22] there is more than one mw-ui-input in some test cases [21:40:01] Krinkle, it doesn't seem to matter if we skip the event - the method accepts the full form [21:40:07] so we should just run it once per form anyways [21:40:12] k [21:40:43] We should probably just call it directly. [21:41:13] Yeah, I'm doing that now, but I am not sure what the best non-messy way it is to expose it [21:41:16] We will need a hack to expose it (mw.flow.ui.enhance.dot.dot.dot), but this code will be going away soon when the editor rewrite is affecting all editors. [21:41:21] yeah [21:41:38] I can just do mw.flow.ui.enhance [21:41:46] mw.flow.ui exists and will stay there anyways [21:41:53] For the future you may also want to avoid too much indirection in assertion. E.g. is(':disabled') is a css selector. Slow and prone to timing errors. What you want is probably .prop('disabled') on the element itself. [21:41:57] which is boolean [21:43:27] Krinkle, I can change those now too if I'm already here [21:44:07] ok this passes [21:44:11] * mooeypoo prepares a commit [21:44:43] As a side note, I don't want to discourage anyone, but for the interest of other teams' productivity, we should consider disabling the test for the time being if we can't find a way to make it pass reliably. – something that applies to flaky tests in general, nothing personal of course. I would've done it already if it weren't for this ping today. [21:45:36] Krinkle, we'll fix it today. Bypassing the setTimeout entirely this way should work. If not, there is another approach I have which is separate event listeners for the paste so the others don't need setTimeout. [21:45:48] Okay :) [21:46:10] * mooeypoo is about to submit a patch [21:46:18] mooeypoo, we should also try to get https://gerrit.wikimedia.org/r/#/c/236206/ merged since other teams can't tell if they broke update.php on Beta since we already broke it (that should fix it I believe). [21:47:21] (03PS1) 10Mooeypoo: Dont trigger event in mediawiki.ui.enhance test [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) [21:47:23] 3Collaboration-Team-Current, 10Beta-Cluster, 5Patch-For-Review, 5WMF-deploy-2015-09-08_(1.26wmf22), 7WorkType-Maintenance: update.php broken in Beta - https://phabricator.wikimedia.org/T111267#1610780 (10Mattflaschen) It does exist on prod, so that patch should restore the config on Labs so that's a vali... [21:47:58] matt_flaschen, I saw it, but I don't understand enough to confirm this issue, and your comment sounded like you're unsure. [21:48:49] Do we need someone from the ops team to review it? [21:48:57] mooeypoo, which comment? [21:49:05] https://gerrit.wikimedia.org/r/#/c/236206/1/wmf-config/InitialiseSettings-labs.php [21:49:28] "I could be wrong" made me not be too sure I should merge it without knowing what I'm doing. [21:49:52] It seems harmless even if you are wrong, but this is ops stuff [21:50:00] I wasn't sure if you're waiting for confirmation [21:50:08] mooeypoo, I was wondering if there's a better way to do it. The way I did it should work, just may not be optimal. I will ask some people. This is not really ops stuff though, it's MW-level, and only affects Labs. [21:50:17] I will ask some people, though. [21:51:05] ah! I missed the "wmfLabsSettings()" [21:51:29] I saw you meant to put it in labs, but the filename + general wgExtraNamespaces property scared me a bit. [21:51:36] I can merge this [21:53:42] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 5WMF-deploy-2015-09-08_(1.26wmf22), 7WorkType-NewFunctionality: Split seen timestamp for alerts and messages - https://phabricator.wikimedia.org/T111285#1610801 (10Etonkovidova) Checked in betalabs. [21:54:04] matt_flaschen, according to the documentation at the top, this should already be there (as in, the property is adding to the one in InitializeSettings... I can merge it, but if that's true, it doesn't sound like it is the fix, no? [21:54:36] mooeypoo or matt_flaschen, what's the current status of the Echo Notification split? Is https://phabricator.wikimedia.org/T108760 likely to be merged before Tuesday? I want to send something to the ambassadors list (and an entry in Tech/News) before it goes live, but it doesn't appear to be ready for screenshots/testing at beta cluster... [21:55:31] The split already happened, but the moving of the talk page messages didn't yet, I think [21:55:43] yep, we were waiting with it [21:56:50] mooeypoo, one sec. [21:57:56] mooeypoo, so for people not using Flow, will there be any noticeable change apart from the icon addition (to the red badge), next week? [21:58:35] Ah, good question. Yes. The popup looks a tad different, and it will show you it is loading while you open it. [21:58:48] if not, I might wait until after the merge of the usertalkpage message split, to announce that part. [21:58:49] Also, mentions will appear in the messages, I believe. [21:58:58] I think [21:58:59] hang on [21:59:02] ty! [21:59:35] quiddity, maybe we can get it merged today (there is no major negative code review, just minor stuff for me to fix). If not, you may want to announce separately. [21:59:44] 6Collaboration-Team-Backlog, 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review: Flaky test "ext.flow: mediawiki.ui.enhance Forms with required fields" - https://phabricator.wikimedia.org/T111459#1610851 (10Mooeypoo) a:3Mooeypoo [22:01:09] mooeypoo, if you do: [22:01:11] mwscript eval.php --wiki=enwiki [22:01:15] var_export( $wgExtraNamespaces ); [22:01:20] matt_flaschen, I think it would be best with one change at a time. So, delay the other, until mid-next week. And for this week, I'll just add a Tech/News mention about the improved icon and loading indication. [22:01:44] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 5WMF-deploy-2015-09-08_(1.26wmf22), 7WorkType-NewFunctionality: Reduce title font size and footprint of topic header - https://phabricator.wikimedia.org/T108263#1610865 (10Etonkovidova) Betalabs - reduced from 1.75em ``` div#content h2.flow-topic-t... [22:02:00] I thought we wanted to do them together because they're related? [22:02:03] matt_flaschen, where? [22:02:12] mooeypoo, on deployment-bastion. [22:02:21] I've never accessed that. [22:02:28] The only namespaces there are Flow_test, Flow_test_talk, TimedText, and TimedText_talk. [22:02:35] * mooeypoo nods [22:02:42] okay so the documentation comment is wrong in general. [22:03:03] matt_flaschen, I can just +2 and see if that fixes things. It shouldn't ruin anything for sure. Should I or are you verifying or something ? [22:03:17] mooeypoo, no, I'm going to do it a better way. [22:03:23] In prod, there are the ones from InitialiseSettings.php, plus TimedText(talk). [22:03:36] bd808 suggested an alternative. [22:03:40] ahh [22:03:48] mooeypoo, if you start with a - it overrides all the wikis I believe (e.g. look at wgServer). [22:04:01] But even otherwise, it still overrides the whole individual wiki, is my understanding. [22:04:12] quiddity, from what I see, mentions appear in "message" tab in echo notifications too. I am not sure about talk page mentions, though. [22:04:27] matt_flaschen, ok, that works too if you're comfortable. But I need to put something in Tech/News a.s.a.p. [22:04:27] matt_flaschen, right, but this key starts with + [22:04:29] ah, ok. [22:05:06] mooeypoo, right, so other wikis (that are neither cawiki nor enwiki) should be unaffected. Whereas starting with a - all wikis have their settings replaced. [22:05:22] But enwiki is still affected (and broken). That's my understanding. [22:05:59] mooeypoo, do you think if I address legoktm's simple feedback we can get the 'move user talk' merged? If not we can tell quiddity not to announce it. [22:06:52] mooeypoo, nope, mentions are still in the "alerts" section, at beta cluster. (just tested) [22:07:14] That's my understanding of where they're supposed to be. mooeypoo, do you mean Flow mentions (I forget where they go)? [22:07:15] matt_flaschen: yes [22:07:29] Okay, will amend that after I get the Beta patch merged. [22:07:30] yeah flow mentions [22:07:35] I need to amend that too. [22:13:31] mooeypoo, you should get access to deployment-bastion sometime, BTW. [22:14:44] matt_flaschen, yeah I already asked for that + introduction to swat stuff [22:15:09] RoanKattouw is going to cover some at least on Monday when the office is empty [22:15:37] https://www.mediawiki.org/wiki/User:Legoktm/deploy [22:15:53] just copy ori's bash files and you'll be good :) [22:16:42] "supersekrit"... ? [22:17:13] when you sync something, it will automatically !log it in #wikimedia-operations. If you set that environment variable (for like security patches), it won't [22:18:09] ah [22:18:30] ok, I'm out to get lunch. bbiab. [22:20:56] its 3pm :< [22:23:17] (03CR) 10Mattflaschen: [C: 04-1] "Looks good except there's still one reference to fake timers. I'll amend this." (031 comment) [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) (owner: 10Mooeypoo) [22:25:39] (03PS2) 10Mattflaschen: Dont trigger event in mediawiki.ui.enhance test [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) (owner: 10Mooeypoo) [22:33:55] (03PS4) 10Mattflaschen: Move edit-user-talk to messages [extensions/Echo] - 10https://gerrit.wikimedia.org/r/231736 (https://phabricator.wikimedia.org/T108760) [22:34:26] (03CR) 10Mattflaschen: Move edit-user-talk to messages (031 comment) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/231736 (https://phabricator.wikimedia.org/T108760) (owner: 10Mattflaschen) [22:34:31] (03CR) 10jenkins-bot: [V: 04-1] Move edit-user-talk to messages [extensions/Echo] - 10https://gerrit.wikimedia.org/r/231736 (https://phabricator.wikimedia.org/T108760) (owner: 10Mattflaschen) [22:34:34] (03CR) 10Mattflaschen: Move edit-user-talk to messages (031 comment) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/231736 (https://phabricator.wikimedia.org/T108760) (owner: 10Mattflaschen) [22:36:55] (03PS5) 10Mattflaschen: Move edit-user-talk to messages [extensions/Echo] - 10https://gerrit.wikimedia.org/r/231736 (https://phabricator.wikimedia.org/T108760) [22:51:08] * legoktm re-tests [23:02:28] mooey|lunch: the notification badge is broken in monobook again? :/ [23:04:54] matt_flaschen: I don't see the orange background..., but the "You have new messages" is updated properly [23:05:17] legoktm, you see the text where it should be, but not the orange background? In monobook? [23:05:24] in vector [23:06:04] matt_flaschen: http://i.imgur.com/FzgRt3F.png [23:06:57] mw.loader.getState('ext.echo.alert'); -> null [23:07:08] legoktm, that's weird. I didn't change any front-end code. While I look at that, could you review https://gerrit.wikimedia.org/r/#/c/236206/ ? [23:07:22] legoktm, also, what do you need reviewed? I should have a bit of time this weekend. [23:08:41] legoktm, email ping, for draft validation, please and thanks. [23:08:50] (03CR) 10Jforrester: Dont trigger event in mediawiki.ui.enhance test (031 comment) [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) (owner: 10Mooeypoo) [23:09:29] (03Abandoned) 10Legoktm: [WIP] Add NotifUser::hasEverHadMessages() [extensions/Echo] - 10https://gerrit.wikimedia.org/r/232872 (owner: 10Legoktm) [23:09:47] (03PS3) 10Mattflaschen: Don't trigger event in mediawiki.ui.enhance test [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) (owner: 10Mooeypoo) [23:09:59] ^ James_F, Be Bold. [23:10:01] matt_flaschen: nothing off the top of my head unless you want to review some extension registration stuff :) [23:10:48] matt_flaschen: Some people don't like me touching their commits in case they over-write. [23:11:12] quiddity: I think it should include some rationale of *why* and a few links to the bug and/or gerrit patch [23:11:13] True, but I already made a bigger amend in that case. [23:11:35] legoktm, nod, I've got those in the mediawiki post, but will add it there, too. [23:12:11] * James_F grins. [23:12:24] legoktm, okay, will try. I still have that in my inbox looking at me. :) One thing re the latest comment, "Yeah. ">= 1.26" or something.", aren't 1.26wmf5 and 1.26-alpha technically *before* 1.26? [23:12:50] So maybe it should be >= 1.26wmf1 or whatever. [23:13:00] And 1.26 should be included in that. [23:13:27] quiddity: also I want to start calling it "cross-wiki notifications", not global. Because global is ambiguous (Wikimedia-wide? MediaWiki-wide?) [23:13:38] nod. will fix. Thanks :) [23:14:41] matt_flaschen: the library currently doesn't support custom suffixes ("wmf") it has "alpha/beta/rc" hardcoded (there's discussion upstream about not doing that, but it won't be ready in time for 1.26). [23:15:19] matt_flaschen: and the library can't parse "1.26wmfXX" at all, because it's not semver (there's another bug about that) [23:15:39] legoktm, why are you using monobooookkkkkk [23:15:46] but it shouldn't be broken, no [23:15:47] monobook4lyfe [23:15:48] legoktm, but still, >= 1.26 probably wouldn't work, right? [23:15:52] LOL [23:16:10] 3Collaboration-Team-Current, 10Flow, 5Patch-For-Review, 5WMF-deploy-2015-09-08_(1.26wmf22), 7WorkType-NewFunctionality: Reduce title font size and footprint of topic header - https://phabricator.wikimedia.org/T108263#1611025 (10DannyH) 5Open>3Resolved Awesome, it looks great. [23:16:20] matt_flaschen: https://gerrit.wikimedia.org/r/#/c/210856/10/tests/phpunit/includes/registration/CoreVersionCheckerTest.php,cm has a bunch of examples [23:16:41] >= 1.26 includes alphas. 1.26.0-stable does not [23:16:56] 1.26.1 does not include alphas. 1.26.0 will include alphas [23:17:09] legoktm, what effects do you see with monobook notifications ? [23:18:00] legoktm, I see. That's non-standard, but I get the reasoning. [23:18:00] mooeypoo: http://i.imgur.com/FiZF1i5.png [23:18:10] legoktm, the only thing that's "Broken" in monobook is the way it looks, which is because of Apex not supporting inverted icons [23:18:14] .. and also because monobook [23:18:23] O.o [23:18:27] legoktm, I see it in monobook [23:18:46] there's no background, and you can barely read the number [23:18:49] ?useskin=monobook and I see the notification badge [23:18:51] what the hell [23:18:54] it works for me [23:19:11] matt_flaschen: https://github.com/wikimedia/mediawiki-extensions-Echo/commit/1ac72cc01ab511605cbf55b1177991dbcf974228 ext.echo.alert accidentally got removed [23:19:12] does beta loads skinStyles ? [23:19:24] module unique skin styles I mean [23:19:29] it should... [23:19:36] :\ it works for me locally. hang on [23:19:38] * legoktm git pulls everything [23:20:02] legoktm, I see it [23:20:20] http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?useskin=monobook <-- it's blue and grey for me because I have unread messages [23:20:22] it works :\ [23:20:30] the only thing that's weird is that the icons aren't white [23:20:32] but that's Apex [23:21:12] ok wtf it works on beta [23:21:13] mooeypoo, how was ext.echo.alert supposed to be addressed? [23:21:33] what? what do you mean? [23:21:38] legoktm found the mini-orange bar disappeared. [23:21:45] legoktm: Do you have an out-of-date MW? [23:21:46] was that removal intentional? [23:21:50] I see you removed those style files, not sure where they're supposed to go instead. [23:22:14] * mooeypoo is confused [23:22:14] Probably most stuff got put in the new file, but not all. [23:22:22] did I forget styles? [23:22:24] where? [23:22:34] mooeypoo, do you know the mini orange bar for 'You have new messages'. The Echo version not the old-school version. [23:22:50] ... I.. shouldn't... have... touched it....? [23:22:52] (but may have) [23:23:00] mooeypoo: ok nvm, my oojs-ui php version was out of date [23:23:00] how do I reproduce this message locally? [23:23:01] James_F: yep [23:23:16] legoktm: :-) [23:23:24] mooeypoo: https://i.imgur.com/FzgRt3F.png the "You have new messages" should have an orange background [23:23:37] crap [23:23:47] okay, I'll bring it back. How do I make it show up? what triggers it? [23:23:50] I think we just need to undelete the ext.echo.alert styles [23:23:58] well, you only half removed it :P [23:24:17] wait, wait do we even need it anymore? Talk page messages go into 'message' popup, no? [23:24:18] there's still a $out->addModuleStyles('ext.echo.alert') call in EchoHooks, so if the module is added back, it'll work again [23:24:21] why is that needed at all? [23:24:39] legoktm, meh, let me look at those styles first [23:25:08] Good question. If we're going to remove it, it should be done fully (there's a user pref and config global) and included in the announcement. [23:25:16] mooeypoo, yes, they go in the messages popup after my change. However, people will probably say Not Nice things if we remove the orange bar. [23:25:26] I mean "Needs separate community consultation". [23:25:30] really? I thought people hated it [23:25:32] ok ok [23:25:35] I'll add it back in [23:25:57] mooeypoo, no, the designers hated the ugly old-school Orange Bar of Death and then we (i.e. past engineers) instituted the smaller one as a compromise. [23:26:10] ahha [23:26:10] After a fair amount of discussion (which was actually pretty constructive) [23:26:18] I thought people were against cluttering the top bar [23:26:25] Well, that too. [23:26:30] At least some people... [23:26:31] and a huge orange message is pretty "cluttery" [23:26:44] mooeypoo, the old one took up way more space, though, albeit in a different place. [23:26:53] * mooeypoo nods [23:26:57] matt_flaschen: Both are horribly ugly kludges. [23:27:26] https://meta.wikimedia.org/w/index.php?title=New_messages_notification&useskin=modern [23:27:37] James_F, yeah, I'm not really against removing the new one, it just isn't worth a whole blow-up so needs to be discussed properly. [23:27:46] Well. [23:27:50] It might be "worth it". [23:27:57] But yes, shouldn't just be slipped out. [23:28:04] That's what I mean. [23:30:23] http://i.imgur.com/cWcZUwq.png :| [23:30:53] wait [23:30:56] <-- stupid [23:31:25] well, it is 4:30pm on a Friday... ;-) [23:31:41] tiredness is allowed. [23:32:17] legoktm, amended the one for update.php: https://gerrit.wikimedia.org/r/#/c/236206/ [23:32:17] * James_F nods. [23:33:04] sanity check draft2 pls, legoktm or anyone https://etherpad.wikimedia.org/p/monkeysisay [23:33:19] (re wikitech-ambassadors announcement) [23:33:35] (03CR) 10Mattflaschen: [C: 031] Don't trigger event in mediawiki.ui.enhance test [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) (owner: 10Mooeypoo) [23:33:57] mooeypoo, also, you can self-merge the enhance one (https://gerrit.wikimedia.org/r/#/c/236209/) if you're happy with my minor change. [23:34:04] I +1'ed it. [23:34:47] matt_flaschen: Or you two can launder it through me. ;-) [23:35:08] quiddity: so much Title Case! [23:35:22] guilty as charged. parentheticals, too! [23:36:29] quiddity: I think it should also say that messages will also include Flow stuff [23:36:35] (03PS1) 10Mooeypoo: Restore echo.alert styles [extensions/Echo] - 10https://gerrit.wikimedia.org/r/236228 [23:36:52] legoktm, matt_flaschen ^^ [23:36:53] legoktm, I want to highlight the mediawiki talkpage link, as much as possible. Can we link that ([4]) inline? [23:37:02] also, legoktm, I restored monobook's corrections for the bar [23:37:06] quiddity: sure [23:37:06] Reviewing [23:37:16] just for you... and whoever else is using monobook [23:37:20] or is it just you? [23:37:39] quiddity: restored [23:37:50] hehe, me and a bunch of enwp sysops ;) [23:38:06] I'll also test in modern later, I know of one user using it [23:38:25] yup. the database results for "who uses monobook" are terrifying (and somewhat misleading, because I forget why) [23:38:38] but in the 10s of thousands, iirc [23:39:03] aww, poor cologneblue [23:39:43] quiddity: echo + cologneblue has always been broken, because their personal tools are in the left sidebar, so the flyout is disabled and it sends you to Special:Notifs directly [23:39:52] ah, right. [23:40:12] ok, I'll send that email now [23:40:29] lgtm :) [23:40:57] matt_flaschen: when I try marking the talk page message as read...it doesn't work. no API request is fired afais [23:41:10] Ug, that worked when I tested it before. [23:42:39] legoktm, yeah I added support for modern, too, but it looks like crap... a lot of it is because the mediawiki and apex themes really don't support modern [23:43:31] mooeypoo: We should just encourage Reading to de-deploy the skins they're not supporting. [23:43:35] Yeah, it totally ruins the modern vibe. I don't know how it looked before, though. [23:43:41] James_F, yes please. [23:44:09] "modern vibe" is probably the LAST vibe that emenated from the modern theme, matt_flaschen [23:44:11] matt_flaschen: Terrible: https://en.wikipedia.org/wiki/User:Jdforrester_(WMF)?useskin=modern [23:44:16] It's "modern" for 1999 [23:44:23] Sorry, that should have been Modern vibe. [23:44:27] :D [23:44:35] matt_flaschen: https://en.wikipedia.org/wiki/User:Jdforrester_(WMF)?useskin=cologneblue is worse, though. [23:44:42] James_F, I can't check since I don't have unread messages right now. Someone want to leave me one real quick? [23:44:43] oh god do I even... [23:45:00] matt_flaschen: Just walk away. :-) [23:45:07] haha [23:45:11] mooeypoo, even Vector is a little misaligned, though. Want me to merge anyway? We can still iterate. [23:45:42] (03CR) 10Legoktm: [C: 032] Restore echo.alert styles [extensions/Echo] - 10https://gerrit.wikimedia.org/r/236228 (owner: 10Mooeypoo) [23:45:50] woot [23:45:58] fastest commit turn around ever [23:46:00] ... for me [23:46:03] ... in Echo [23:46:33] mooeypoo, I was just reading an article about the appeal of a record for solving Rubik's cubes on a unicycle. [23:46:45] matt_flaschen, i think that's not the misalignment, I think the echo *badge* is misaligned [23:46:49] and plays tricks on us [23:46:59] we should align it, but so far our attempts were unsuccessful [23:47:13] ... matt_flaschen how did that happen [23:47:32] (03Merged) 10jenkins-bot: Restore echo.alert styles [extensions/Echo] - 10https://gerrit.wikimedia.org/r/236228 (owner: 10Mooeypoo) [23:47:35] you reading the article, not the solving of the Rubik's cube on a unicycle. Okay, maybe both. [23:47:43] mooeypoo, not Just as in like today. [23:48:29] Can someone re-review https://gerrit.wikimedia.org/r/#/c/236206/ so I can deploy it before I leave? [23:49:31] It looks good to me, but I have no way of testing it. You want me to +2 ? [23:49:54] ... I take that back, I can't +2 [23:49:58] matt_flaschen, I only have +1 [23:50:03] mooeypoo, I don't think anyone has that set up to test locally. It only affects Beta, but I'm hoping to fix https://integration.wikimedia.org/ci/view/Beta/job/beta-update-databases-eqiad/ . [23:50:08] matt_flaschen: +1'd [23:50:29] mentally +1'ed [23:53:25] (03CR) 10Mooeypoo: [C: 032] "Following matt's +1, this is good to go." [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) (owner: 10Mooeypoo) [23:54:49] It's fixed, gotta go. [23:55:39] (03Merged) 10jenkins-bot: Don't trigger event in mediawiki.ui.enhance test [extensions/Flow] - 10https://gerrit.wikimedia.org/r/236209 (https://phabricator.wikimedia.org/T111459) (owner: 10Mooeypoo)