[00:00:04] and, then the setValue gets cleaned up, and then we only emit if there was an actual change [00:00:34] right [00:01:15] so maybe 'change' is not a 'direct' event [00:01:28] 3VisualEditor: [Regression pre-wmf10] Cannot close Citation dialog , error in the console:TypeError: this.outlineSelectWidget is undefined - https://phabricator.wikimedia.org/T75942#786655 (10Jdforrester-WMF) [00:02:00] my point is, our change events are very abstract, maybe you want to have a subclass that pays attention to the key state, and then emit a different event that includes mofiier key information [00:02:29] like an input event [00:02:31] for instance [00:02:50] I'm not talking about change events necessarily [00:03:09] yeah, I get that - that's why I'm suggesting that you have a different event [00:03:18] ryasmeen: T75942 fixed now? [00:03:30] because, change isn't unique, most of our events are abstracted a lot [00:03:45] checking James_F [00:03:46] click is the closest thing we have [00:04:06] highlight, select, choose - these are very separated from the events that triggered them [00:04:20] so, doing things like CTRL+Click to choose an item will be tricky [00:04:22] not yet James_F, maybe wait for a while? [00:04:38] edsanders: RE: "is there a good way to detect if you script is being loaded sync or async?" [00:04:50] edsanders: script as in, a module? [00:05:03] and I'm open to ideas about how to make that less tricky - I'm just suggesting that the change event situation is the rule not the exception [00:05:11] script as in script [00:05:23] ryasmeen: Maybe? [00:05:24] edsanders: context [00:05:38] Krinkle: the conversation was mostly around whether to use doc write or DOM [00:05:55] 3VisualEditor: Use [[ as a 'hotkey' trigger for opening the 'create a link' dialog - https://phabricator.wikimedia.org/T52093#786670 (10Jdforrester-WMF) 5declined>3Open a:5rmoen>3None [00:06:01] TrevorParscal: always DOM, unless you need to block the html parser for the main document, in which case you use doc.write [00:06:15] 3VisualEditor: Use [[ as a 'hotkey' trigger for opening the 'create a link' dialog - https://phabricator.wikimedia.org/T52093#564242 (10Jdforrester-WMF) This is no longer catastrophically expensive to do. Yay. [00:06:31] TrevorParscal: Is this about resourceloader?\ [00:06:37] sort of [00:06:43] it's the Papa Parse lib [00:06:44] 3VisualEditor: Use [[ as a 'hotkey' trigger for opening the 'create a link' dialog - https://phabricator.wikimedia.org/T52093#786682 (10Jdforrester-WMF) [00:07:11] 3VisualEditor, VisualEditor-MediaWiki: VisualEditor: Entering ";" does not trip the wikitext warning that it won't work - https://phabricator.wikimedia.org/T71689#786683 (10Jdforrester-WMF) [00:07:28] 3VisualEditor, VisualEditor-MediaWiki: Entering ";" does not trip the wikitext warning that it won't work - https://phabricator.wikimedia.org/T71689#786686 (10Jdforrester-WMF) [00:07:38] edsanders: I saw that name earlier in the standaup [00:07:56] edsanders: Is there a bug or patch about this? [00:08:39] Seems like that sort of lib shouldn' t be concerned about that [00:09:00] https://github.com/edg2s/PapaParse/commit/65388f3d50695a2aedaece2c8b3387248393bf3a [00:09:14] it uses worker threads so needs to know it's own path [00:10:07] * its [00:10:57] edsanders: what csv files are we dealing with? [00:11:10] larger context :) [00:11:25] Krinkle: Ones that users drag in. [00:11:27] drag and drop [00:11:29] blame James [00:11:42] Blame users. [00:13:30] ryasmeen: betalabs does not have a help icon anymore - oo-ui-icon-help. Is it a "new feature"? Or just a bug ? [00:14:54] wtf [00:14:57] etonkovidova: Where? [00:14:57] etonkovidova: bug I believe :( if you could file it [00:15:05] Patterns like scripts[scripts.length-1] to get the script path are no associated with the quality levels of software we want to be using. It may be state of the art in its data model, but when it comes to reality in browsers and javascript developments, that's not gonna work in any modern or large scale environment. [00:15:38] For a Worker app like that, I think there are better established patterns. But off hand I can think of one: [00:16:33] ryasmeen: sure - I will [00:16:46] Krinkle: lol [00:16:49] default to no script path, by the time the library is called from user code, assume the user has set the proper path. If not, either throw, or (if you want to spoonfeed little applications) do some best effort approach as fallback like what it does now (assume loaded by standalone file etc.) [00:16:57] ryasmeen: Roan just saw it and he thinks he is fixing it :) [00:17:07] Alternatively, if it only needs to load itself. [00:17:07] @ "Patterns like scripts[scripts.length-1] to get the script path are no associated with the quality levels of software we want to be using" [00:17:20] it could just.. load itself. [00:17:23] this.toString() [00:17:30] and pass that to the worker as direct script. [00:17:59] I realise that's upstream though, and from what i hear, they're not flexible to take advice from professionals.. [00:18:10] So.. I guess Ed's forking it. [00:18:11] Krinkle: that might be a little extreme, I'm not guaranteeing that I'm right, but I'm pretty confident this isn't a bad way to get the blocking script tag being currently executed during page load [00:18:11] Cool :) [00:18:33] TrevorParscal: True, but that premise is too narrow to begin with. [00:18:46] 3VisualEditor: oo-ui-icon-help is missing in beta - https://phabricator.wikimedia.org/T75946 (10Etonkovidova) 3NEW p:3High a:3Catrope [00:18:54] TrevorParscal: Taking a gun and pointing it at your foot and pulling the trigger is an extremely effective way of shooting yourself in the foot. [00:19:01] But you may not want to be doing that. [00:19:41] I'm saying that, in a very narrow case, it's not dangerous at all, but any other case I wouldn't expect it to work [00:20:25] A library shouldn't need to know where it's hosted. Things get concatenated. Or loaded by a module. Or even dynamically generated. Or loaded from websockets, or localstorage, or indeed resourceloader. [00:20:38] and if you think I'm crazy, just take it from your boy John Resig http://ejohn.org/blog/degrading-script-tags/ [00:21:18] and in the case of a ResourceLoader, it actually DOES need to know where to ask for more modules [00:22:09] TrevorParscal: yes. The module loader it configured to load modules from a certain place. Because it's agnostic in that way. [00:22:33] that's the case I was making - I agree that other cases are suspect [00:22:45] But it wouldn't need to know where it itself is hosted. [00:23:05] So the worker wouldn't work anyway in RL [00:23:08] 3VisualEditor, VisualEditor-EditingTools: VisualEditor: Link input widget should have separate inputs for target and display text - https://phabricator.wikimedia.org/T55973#786734 (10Jdforrester-WMF) [00:23:10] 3VisualEditor: Add a "display text" field in the link inspector - https://phabricator.wikimedia.org/T75726#786733 (10Jdforrester-WMF) [00:23:24] edsanders: It'd work just fine. It is given the configuration at run time, which it can pass to the worker. [00:23:46] whether you deduce it by reading the src attribute of the currently executed script tag while executing the startup module or bundle the URL as part of the startup module makes no difference, the startup module does need to know how to ask for the initial payload [00:24:04] the script url communicates only information to the server. The client doesn't know anything about the url it got requested with. [00:24:34] how is my patch different? it only uses auto_script_path if script_path isn't set [00:24:46] I haven't looked at your patch yet in detail. [00:24:48] edsanders, TrevorParscal, Krinkle: Don't you all have more important bugs to fix? ;-) [00:24:51] (03PS9) 10SuchetaG: [WIP] Link Inspector Redesign [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/174725 [00:24:52] I was referring to the way it did it originally. [00:25:02] not your approach. [00:25:08] no James_F, someone is wrong on the internet! [00:25:15] Krinkle: no worries [00:25:43] TrevorParscal: :-P [00:26:12] right [00:26:20] I know that is wrong [00:26:35] TrevorParscal: Given the current time and reality we live in, libraries that need to load more should either settle on a loader (e.g. "we support AMD, and best viewed in IE4 with 800x600 display"), or provide a configuration fo the user to provide their own. [00:27:26] "You're the only one to speak up who's refused to hard-code the path [INTO THE LIBRARY!!!]. ... I wish you the best of luck." [00:28:08] And if it only needs to load itself, it wouldn't need a path of any kind. [00:28:44] if you have any improvements feel free to edit my fork [00:28:58] 3VisualEditor, VisualEditor-MediaWiki: Toolbar help menu doesn't render nicely if the alert (edit notices) other half of the group isn't active - https://phabricator.wikimedia.org/T63575#786740 (10Jdforrester-WMF) 5Open>3Resolved [00:29:06] I'm not the one working on it :) [00:29:16] 3VisualEditor, VisualEditor-MediaWiki, VisualEditor-ContentEditable: Preserve `data-parsoid` attribute on internal copy-paste so that Parsoid preserves e.g. syntax layout - https://phabricator.wikimedia.org/T74426#786749 (10Jdforrester-WMF) [00:29:23] edsanders: Does it load more code or the same code? [00:29:24] 3VisualEditor, VisualEditor-MediaWiki, VisualEditor-ContentEditable: Preserve `data-parsoid` attribute on internal copy-paste so that Parsoid preserves e.g. syntax layout - https://phabricator.wikimedia.org/T74426#786750 (10Jdforrester-WMF) 5Open>3Resolved [00:30:30] I'm not reading any of the code, just answering questions. Seems more useful for both our times. I can drop what I'm working on and dig into it, but I think you've got it loaded in memory already so that's probaby more useful. [00:31:22] 3VisualEditor, VisualEditor-EditingTools: When user inputs */1. at the start of the line, make it a bulletted/numbered list - https://phabricator.wikimedia.org/T53408#786755 (10Jdforrester-WMF) [00:31:30] James_F: Is this new, or did we just recently upgrade? This was never enabled in ve-mw, right? Like, the parsing in workers is not a new aspect, that was always there. [00:31:38] Krinkle: New. [00:31:52] 3VisualEditor, Parsoid: Parsoid: Page redirect is not working on betalabs - https://phabricator.wikimedia.org/T63403#786757 (10Arlolra) [00:32:09] 3VisualEditor, Parsoid: Parsoid: Page redirect is not working on betalabs - https://phabricator.wikimedia.org/T63403#786759 (10Arlolra) [00:32:51] 3MediaWiki-ResourceLoader: Merge