[00:04:04] <grrrit-wm>	 (03CR) 10Alex Monk: [C: 04-1] "I think this breaks the animation as well actually..." [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/179551 (owner: 10Alex Monk)
[00:07:16] <grrrit-wm>	 (03CR) 10Bartosz Dziewoński: Eventify TemplateDataGenerator and use oojs-ui (035 comments) [extensions/TemplateData] - 10https://gerrit.wikimedia.org/r/167046 (owner: 10Mooeypoo)
[00:08:37] <MatmaRex>	 mooeypoo: review done, i think, mostly. :)
[00:12:21] <mooeypoo>	 MatmaRex, awesome, thanks!
[00:16:49] <James_F>	 Krinkle: https://gerrit.wikimedia.org/r/#/c/177901/ <-- Jenkins took 49 minutes to run tests. :-(
[00:17:00] <James_F>	 Krinkle: (Also, feel free to merge if you're OK with it.)
[00:19:35] <Krinkle>	 James_F: Zuul was stuck for an hour. I think antone was looking into it
[00:19:57] <James_F>	 Krinkle: Aha, OK. Fun.
[00:20:51] <grrrit-wm>	 (03CR) 10Bartosz Dziewoński: [C: 04-1] "I think these classes actually intentionally don't have @noflip and are supposed to be flipped; they are just badly named. Applying this p" [oojs/ui] - 10https://gerrit.wikimedia.org/r/179565 (owner: 10Amire80)
[00:21:35] <wikibugs>	 3VisualEditor, VisualEditor-InterfaceLanguage, OOjs-UI: VisualEditor page options menu goes off-screen in RTL wikis - https://phabricator.wikimedia.org/T76474#845278 (10matmarex) The real issue is that ClippableElement doesn't handle clipping with the left edge of browser window, only with the right edge.
[00:35:07] <grrrit-wm>	 (03PS1) 10Jforrester: Update VE core submodule to master (6103755) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/179579 
[00:43:41] <James_F>	 Hey RoanKattouw. :-)
[00:43:54] <MatmaRex>	 bah
[00:44:06] <MatmaRex>	 there's something really wrong with ClippableElement
[00:44:19] <RoanKattouw>	 Hello
[00:44:19] <James_F>	 RoanKattouw: Sadly the native cursoring thing got some pretty damning review from mooey|away and divec is busy trying to fix.
[00:44:25] <James_F>	 RoanKattouw: No last-minute merge-and-fly on that.
[00:44:40] <MatmaRex>	 http://i.imgur.com/UcneAb4.png
[00:44:45] <RoanKattouw>	 Apparently my laptop doesn't like the free wifi at SFO, so it's tethering time
[00:44:46] <RoanKattouw>	 To be fair it also went to sleep for being dangerously low on battery... at 93%
[00:44:48] <James_F>	 MatmaRex: Eww.
[00:44:49] <RoanKattouw>	 Oh oops
[00:44:51] <RoanKattouw>	 Will catch up
[00:44:52] <RoanKattouw>	 Also, I will allegedly have in-flight wifi + power
[00:44:58] <James_F>	 RoanKattouw: Ha.
[00:45:01] <MatmaRex>	 to reproduce: open OOUI toolbars demo, open that dropdown, and carefully bring the right edge of browser window close to it
[00:45:11] <RoanKattouw>	 [16:43]	James_F	[2014-12-12 15:17:54] Krinkle|detached: Did RoanKattouw_away give you CR on your ResourceLoaderInOneFileOMG commit?
[00:45:13] <RoanKattouw>	 No I did not
[00:45:16] <MatmaRex>	 as you move closer, the dropdown will grow wider.
[00:45:23] <James_F>	 RoanKattouw: OK, there's your job for the gate wait. :-)
[00:45:57] <James_F>	 MatmaRex: Sounds… curiously broken.
[00:46:10] <James_F>	 MatmaRex: Is the update code adding rather than taking away or something?
[00:46:13] <grrrit-wm>	 (03PS1) 10Bartosz Dziewoński: [WIP] ClippableElement: Handle clipping with left edge [oojs/ui] - 10https://gerrit.wikimedia.org/r/179581 
[00:46:17] <MatmaRex>	 James_F: i don't even
[00:46:26] <MatmaRex>	 found that when working on this ^
[00:46:27] <James_F>	 MatmaRex: :-)
[00:46:38] <MatmaRex>	 which actually seems to work, i didn't really expect it to.
[00:46:52] <James_F>	 Hmm.
[00:47:37] <mooeypoo>	 RoanKattouw, can I ask you a quick question or are you running for your flight?
[00:47:44] <James_F>	 mooeypoo: Ask.
[00:47:49] <grrrit-wm>	 (03CR) 10Catrope: "Trevor looked at this earlier and said that you couldn't do it this way for pretty much that exact reason, yeah" [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/179551 (owner: 10Alex Monk)
[00:48:18] <RoanKattouw>	 mooeypoo: Ask
[00:48:27] <RoanKattouw>	 I'm waiting for them to finish cleaning the plane
[00:49:00] <mooeypoo>	 RoanKattouw, the API is giving us answers that have html in them. Sometimes it's good, like when you have a username with link to the user's profile in whatever-wiki, but I have a feeling it is a recipe for disaster. Some of it I'm trying to strip (like the 'credit') but even that, I'm not sure I'm doing right. 
[00:49:28] <mooeypoo>	 this smells fishy to me, I want to verify it's a good way to go at it. I am wrried about Bad Things we receive, since it's really all user generated.
[00:49:53] <grrrit-wm>	 (03CR) 10Amire80: [C: 031] [WIP] ClippableElement: Handle clipping with left edge [oojs/ui] - 10https://gerrit.wikimedia.org/r/179581 (owner: 10Bartosz Dziewoński)
[00:49:53] <wikibugs>	 3OOjs-UI: ClippableElement PopupToolGroup near right side of viewport hilariously broken - https://phabricator.wikimedia.org/T78447#845319 (10matmarex) 3NEW
[00:49:55] <grrrit-wm>	 (03CR) 10Catrope: [C: 032] Check for stopped propagation before showing close dialog [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/179478 (owner: 10Esanders)
[00:49:57] <mooeypoo>	 so, look for instance at line #470: https://gerrit.wikimedia.org/r/#/c/161342/20/modules/ve-mw/ui/dialogs/ve.ui.MWMediaDialog.js
[00:50:17] <mooeypoo>	 and line #481 specifically, for the credit
[00:50:19] <grrrit-wm>	 (03Abandoned) 10Amire80: Add noflip to oo-ui-popupToolGroup-left and -right [oojs/ui] - 10https://gerrit.wikimedia.org/r/179565 (owner: 10Amire80)
[00:50:27] <Krenair>	 RoanKattouw, yeah I had no other ideas..
[00:50:37] <grrrit-wm>	 (03CR) 10Catrope: [C: 032] Update VE core submodule to master (6103755) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/179579 (owner: 10Jforrester)
[00:50:51] <James_F>	 RoanKattouw: Ta.
[00:51:30] <RoanKattouw>	 mooeypoo: Hmmmm yeah
[00:51:31] <mooeypoo>	 RoanKattouw, sometimes we get a non-html link (plain text http://blablabla ) and sometimes an <a href=...> and sometimes "Own work". It's lovely how it's all consistent. So I'm testing if it starts with a link (plaintext http) and if it does, I create a link with attr( 'href', $( metadata.Credit.value ).text() ) but if it doesn't, I embed as-is
[00:51:41] <RoanKattouw>	 So, I wonder where that HTML comes from exactly
[00:51:51] <RoanKattouw>	 If it comes from the wikitext parser it's probably relatively sane, security-wise at least
[00:51:51] <mooeypoo>	 RoanKattouw, users are inputting it into templates
[00:51:58] <RoanKattouw>	 Sure but as wikitext right?
[00:52:02] <mooeypoo>	 I think so
[00:52:17] <mooeypoo>	 RoanKattouw, here's the main issue, though. This: if ( metadata.Credit.value.match( /^https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=
[00:52:18] <mooeypoo>	 ]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)/ ) ) {
[00:52:26] <mooeypoo>	 this is searching for whether the result *starts* with a link
[00:52:28] <RoanKattouw>	 mooeypoo: Why make the regex so complicated? Why not just assume that anything that starts with https?:\/\/ is a URL?
[00:52:58] <grrrit-wm>	 (03Merged) 10jenkins-bot: Check for stopped propagation before showing close dialog [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/179478 (owner: 10Esanders)
[00:53:02] <grrrit-wm>	 (03Merged) 10jenkins-bot: Update VE core submodule to master (6103755) [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/179579 (owner: 10Jforrester)
[00:53:03] <mooeypoo>	 I had it before as checking whether it *has* a link, anywhere, but then I found an instance of someone inputting something like "This is from <a href="http://somethingsomething.com/">somethingsomething</a> and is awesome"
[00:53:32] <RoanKattouw>	 <_<
[00:53:34] <mooeypoo>	 so now this ^^ won't get translated to "Credit" with a link, but it WILL be inserted as-is (stripped, since I used .text() ) if that makes sense
[00:53:46] <mooeypoo>	 so we'll see "This is from somethingsomething and is aewsome" sans link
[00:53:54] <mooeypoo>	 but I'm really worried appending things as-is like that :\
[00:53:58] <mooeypoo>	 then again, I do it for Artist
[00:54:17] <mooeypoo>	 and we saw that returned some annoyingly huge html-filled result
[00:54:24] <mooeypoo>	 RoanKattouw, my *main* concern is security though
[00:54:56] <mooeypoo>	 We'll need to figure out at some point a sane way of stripping stuff, but is it *secure* using the method i am using? embedding things as-is or $( string ).text() 
[00:55:12] <mooeypoo>	 because evcen with .text() I think jQuery is running/parsing it first, right? can that hold a security risk?
[00:55:21] <MatmaRex>	 it isn't
[00:55:23] <MatmaRex>	 text is text
[00:55:43] <mooeypoo>	 okay, and $div.append( $( string ) ) is?
[00:55:52] <MatmaRex>	 yes
[00:55:54] <mooeypoo>	 god knows what can be in there. It's user-generated.
[00:55:56] <grrrit-wm>	 (03CR) 10jenkins-bot: [V: 04-1] [WIP] ClippableElement: Handle clipping with left edge [oojs/ui] - 10https://gerrit.wikimedia.org/r/179581 (owner: 10Bartosz Dziewoński)
[00:55:58] <mooeypoo>	 :\
[00:56:03] <mooeypoo>	 So I'll have to strip it all?
[00:56:14] <MatmaRex>	 .append( document.createTextNode( string ) )
[00:56:23] <mooeypoo>	 That's better??
[00:56:32] <RoanKattouw>	 Well that'll treat it as plain text
[00:56:37] <MatmaRex>	 well, that doesn't accept HTML in the string?
[00:56:43] <MatmaRex>	 i think i lack context
[00:56:43] <mooeypoo>	 hm that won't parse <a> and such
[00:56:46] <MatmaRex>	 also sleep
[00:56:47] <RoanKattouw>	 Even if it contains <a href="garbage">like this</a> it'll just render as plain text
[00:56:55] <MatmaRex>	 so, good night :)
[00:57:02] <mooeypoo>	 MatmaRex, night!
[00:57:05] <mooeypoo>	 and thanks for the review :)
[00:57:06] <RoanKattouw>	 mooeypoo: Krinkle knows best, but IIRC .append() isn't totally safe but $.parseHTML() is
[00:57:10] <James_F>	 Bye MatmaRex!
[00:57:14] <RoanKattouw>	 Mostly wrt <script> tags in the input
[00:57:15] <mooeypoo>	 hmmmmmm okay. 
[00:57:28] <RoanKattouw>	 mooeypoo: However presumably this isn't totally user-generated HTML, but HTML generated from user-generated wikitext?
[00:57:31] <mooeypoo>	 RoanKattouw, it all comes from wikitext, so I assume script is not a danger
[00:57:38] <mooeypoo>	 yeah
[00:57:54] <mooeypoo>	 presumably... users can also write html directly, I think? 
[00:57:56] <RoanKattouw>	 Yeah exactly
[00:58:12] <mooeypoo>	 will the template strip <script> tag if the user explicitly put it in there?
[00:58:17] <RoanKattouw>	 mooeypoo: That's heavily sanitized
[00:58:28] <RoanKattouw>	 You can write certain things like <span dir="rtl">
[00:58:39] <RoanKattouw>	 But things like <script> will be turned into &lt;script&gt; by the parser
[00:58:50] <mooeypoo>	 I'm very meh appending something I have no idea what it is... unless we are certain it's sanitized. Maybe I'm worried for nothing.
[00:58:59] <RoanKattouw>	 Yeah no I think you're right to be worried
[00:59:15] <Krinkle>	 RoanKattouw: mooeypoo: Always use parseHTML to convert HTML into a dom node
[00:59:20] <RoanKattouw>	 For many of these fields it's probably sane to say "either it's a URL or I'm going to cast it all down to plain text"
[00:59:30] <mooeypoo>	 Krinkle, okay, not $( ... ) ?
[00:59:52] <mooeypoo>	 Krinkle, security-wise do we have anything to worry about with API responses based on user-generated wikitext ?
[00:59:56] <mooeypoo>	 that's what we're getting from the API
[01:00:19] <RoanKattouw>	 Note that, unhelpfully, $.parseHTML() returns an array, not a jQuery object
[01:00:29] <RoanKattouw>	 So you need $( $.parseHTML( htmlString ) ) in order to do anything useful
[01:00:37] <Krinkle>	 RoanKattouw: Most methods take arrays
[01:00:44] <Krinkle>	 at least those that take jQuery objects.
[01:00:53] <RoanKattouw>	 True
[01:01:01] <RoanKattouw>	 If you're feeding it to something like .append() that'll work
[01:01:18] <RoanKattouw>	 But if you wanted to, say, mangle it so that all <a>s have target=_blank
[01:01:18] <mooeypoo>	 users fill out the fields, and while they are usually okay with filling out "artist=username" they sometimes go crazy.
[01:01:37] <RoanKattouw>	 Then you need $( $.parseHTML( htmlString ) ).find( 'a' ).each( ... ); or something
[01:02:29] <mooeypoo>	 See, I can't really do anything sane with looking for links or whatever when the information is so inconsistent
[01:02:39] <mooeypoo>	 if I knew that the info is mostly text with links, I could plan for that
[01:03:07] <Krinkle>	 mooeypoo: The main difference between $() and parseHtml is whether it considers it a fragment or a fresh document. Which manifests itself in whether <script> is removed or not.
[01:03:19] <Krinkle>	 mooeypoo: There is also an edge case when it comes to html before or after the tag.
[01:03:21] <mooeypoo>	 but the info is just ... random. Seriously. There's a majority of sanity, but then a large minjority of random crap people just put in the various fields.
[01:03:24] <Krinkle>	 Especially whitespace.
[01:03:33] <Krinkle>	 long story short: $() is ambiguous. 
[01:03:35] <Krinkle>	 $(foo)
[01:03:44] <Krinkle>	 could do dom-ready, selecting, parsing, ...
[01:03:49] * mooeypoo nods
[01:03:53] <mooeypoo>	 thta's what I was worried about
[01:03:59] <Krinkle>	 if you start with whitespace and then html, you meant html, but it;ll probably select.
[01:04:01] <mooeypoo>	 especially if I don't know what it is
[01:04:12] <Krinkle>	 So best to be explicit in that ase
[01:04:23] <Krinkle>	 as of jQuery 1.9, $() uses $.parseHTML once it thinks it is html.
[01:04:31] <Krinkle>	 but with extra parameter keepScripts=true
[01:04:37] <Krinkle>	 which is not the default for parseHTML.
[01:04:44] <mooeypoo>	 okay, so safer to use $.parseHTML first and then append whatever I get
[01:04:45] <mooeypoo>	 ?
[01:04:58] <RoanKattouw>	 Yeah I suppose most CSS selectors are also valid HTML
[01:05:18] <RoanKattouw>	 That would be really fun to exploit, injecting 'body' as an HTML string and watching random code crap itself
[01:06:06] * mooeypoo is worried about that exactly
[01:06:14] <RoanKattouw>	 I hadn't thought of that
[01:06:23] <mooeypoo>	 it's so hard to program -- even defensively -- when the output is unpredictable like that
[01:06:28] <mooeypoo>	 and I know that $() is really powerful 
[01:06:35] <mooeypoo>	 so I was really worried it can be taken advantage of
[01:08:02] <mooeypoo>	 I could as a matter of principle just strip *everything*
[01:08:19] <mooeypoo>	 but that has the downside of either losing the link to user pages and credit pages 
[01:08:34] <mooeypoo>	 or having to jump through fiery hoops to get them back after stripping
[01:08:56] <Krinkle>	 mooeypoo: I think the only thing nowadays $() can do is allow the user to shoot themselves in the foot when thinking they're hacking our code. Looks cool, but nothing of worry. That functionality was deprecated in 1.8 and removed in 1.9 and last week we remove d the migrate pplugin taht added it back in.
[01:08:58] <mooeypoo>	 If I can find a safe way to semi-strip (to at least make whatever is appended *SAFE*) then that solves most of the cases, I think.
[01:09:38] <mooeypoo>	 Krinkle, okay, at least that, good to know. I'm not as worried. 
[01:09:43] <Krinkle>	 There is still the ambiguation, so it might become a css selector instead of html, but that seems hard to exploit. 
[01:09:46] <RoanKattouw>	 Well, depends on what you mean by "safe"
[01:09:55] <mooeypoo>	 I should probably still go with $.parseHTML() though, before appending
[01:09:59] <Krinkle>	 Yes
[01:10:01] <RoanKattouw>	 I'm not too worried about security given that it comes from the wikitext parser
[01:10:10] <mooeypoo>	 RoanKattouw, as safe as possible considering the responses from the API are all over the place
[01:10:10] <RoanKattouw>	 But I am a bit worried about random-ass content appearing in all these fields
[01:10:14] <Krinkle>	 just pretend append() only takes nodes, arrays of nodes and jquery objects.
[01:10:19] <mooeypoo>	 RoanKattouw, yeah, well, that too :\
[01:10:33] <RoanKattouw>	 Like in that email you sent earlier this week, who knows what kind of random crap with struck-through dollar symbols people will put in there
[01:10:38] <mooeypoo>	 RoanKattouw, I'm not sure how we can solve that except for removing all that data and saying "MORE INFO" with link t othe image page
[01:10:45] * Krinkle would like to make a jshint-jquery plugin that forbids calling append() with strings.
[01:10:46] <RoanKattouw>	 Hmm right
[01:10:47] <mooeypoo>	 yes exactly
[01:10:54] <RoanKattouw>	 You could cut it off after a certain # of chars
[01:10:55] <mooeypoo>	 hence "as safe as possible"
[01:10:57] <RoanKattouw>	 And have an expand control
[01:11:10] <mooeypoo>	 RoanKattouw, well, sure, but then if I don't strip HTML I might end up with unbalanced tags
[01:11:31] <RoanKattouw>	 $.parseHTML() can deal
[01:11:36] <mooeypoo>	 RoanKattouw, also, it's really annoying, that particular field "Artist" is *supposed* to be *SHORT*
[01:11:44] <mooeypoo>	 whoever it was that did this worked backwards
[01:11:46] <Krinkle>	 RoanKattouw: There also used to be the xss vector of people doing if (location.hash.length) $( location.hash ).something
[01:11:52] <mooeypoo>	 so, ideally, we should fix the image itself
[01:11:55] <Krinkle>	 wich start with # and then the id of an element
[01:11:59] <RoanKattouw>	 Krinkle: LOL that sounds concerning
[01:12:04] <RoanKattouw>	 Krinkle: Ooooh I see
[01:12:08] <mooeypoo>	 I don't think i was representative. But it *did* expose an inherent problem
[01:12:17] <Krinkle>	 harmless, until you realise that if there's html-like characters, it might decide to parse as html with a textnode '#' in front of it
[01:12:25] <RoanKattouw>	 Krinkle: 'foo.html#garbage,body'
[01:12:41] <Krinkle>	 $('#<p>Hello</p>')
[01:12:50] <Krinkle>	 Nowadays, parsing html with $() requires < and > at begin and end.
[01:12:57] <Krinkle>	 no textnodes before or after.
[01:13:10] <Krinkle>	 it can still have siblings though, just lke parseHTML
[01:13:30] <Krinkle>	 $('<br/><br/>')
[01:14:08] <mooeypoo>	 Krinkle, it does parse $( 'something <a href='http://foo'>foo</a> else' )
[01:14:50] <mooeypoo>	 or, well, with proper quotes
[01:15:17] <mooeypoo>	 ... at lesat it did in the code. Doesn't now in the console. Hm.
[01:15:37] <RoanKattouw>	 mooeypoo: BTW could you vote -1 on divec's Gerrit change with a description of what broke for you?
[01:15:39] <mooeypoo>	 oh oh
[01:15:39] <mooeypoo>	 $('<div>').append( 'something <a href="http://foo">foo</a> else' )
[01:15:42] <RoanKattouw>	 You said it here on IRC but I'd like a record to exist
[01:15:46] * mooeypoo nods
[01:15:50] <RoanKattouw>	 mooeypoo: Yeah .append() will parse anything
[01:15:56] <RoanKattouw>	 $() hopefully doesn't parse that though
[01:16:11] <Krinkle>	 mooeypoo:  $( 'someth ..' ) is a css selector. Will throw uncaught from querySelector engine
[01:16:31] <mooeypoo>	 uhm... shoot i an't find divec's fix in gerrit
[01:16:48] <mooeypoo>	 Krinkle, aye. I used the append thing, hence my initial concern
[01:16:53] <Krinkle>	 $( 'something <a href="http://foo">foo</a> else' )
[01:16:53] <Krinkle>	 Uncaught Error: Syntax error, unrecognized expression: something <a href="http://foo">foo</a> else
[01:16:54] <mooeypoo>	 that seems like it's terribly unsecure
[01:17:23] <Krinkle>	 in .append() it works though, interestingly
[01:17:31] <Krinkle>	 eventhough append also takes css selectors, like $()
[01:17:36] <Krinkle>	 seems the logic is inconsistent
[01:17:38] <mooeypoo>	 $('<div>').append( 'something <a href="http://foo">foo</a> else' ) <-- this is what I've done mostly and that seems terrible
[01:17:47] <RoanKattouw>	 OK boarding time
[01:17:49] <mooeypoo>	 $('<div>').append( answer.from.API )
[01:17:51] <Krinkle>	 Yep, use paseHTML there
[01:17:52] <mooeypoo>	 ^^ bad
[01:17:55] <RoanKattouw>	 See you guys in a minute, assuming the in-flight wifi isn't a lie
[01:18:02] <mooeypoo>	 RoanKattouw, have a safe flight!
[01:18:16] <mooeypoo>	 I actually have to run to a birthday party in a minute
[01:20:57] <Krinkle>	 Ah, right. append() isn't inconsistent about what it considers html. append() doesn't take a selector. string is always html
[01:21:51] <Krinkle>	 http://api.jquery.com/append/
[01:21:51] <Krinkle>	 """"
[01:21:52] <Krinkle>	 By design, any jQuery constructor or method that accepts an HTML string — jQuery(), .append(), .after(), etc. — can potentially execute code. This can occur by injection of script tags or use of HTML attributes that execute code (for example, <img onload="">). Do not use these methods to insert strings obtained from untrusted sources such as URL query parameters, cookies, or form inputs. D
[01:21:53] <Krinkle>	 oing so can introduce cross-site-scripting (XSS) vulnerabilities. Remove or escape any user input before adding content to the document.
[01:21:55] <Krinkle>	 """
[01:22:20] <grrrit-wm>	 (03CR) 10Mooeypoo: [C: 04-1] "As mentioned on IRC, there is a problem when moving the cursor in RTL across a sentence that has an inline image in it. Like this:" [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/177946 (owner: 10Divec)
[01:23:18] <mooeypoo>	 Krinkle, aha. Oi. I'll make sure I use $.parseHTML then... yikes.
[01:23:45] <Krinkle>	 mooeypoo: for actual user input, use mw.html.escape (or $().text) of course. 
[01:24:06] <mooeypoo>	 Krinkle, yeah, I can't tell which is stripped text and which actually has useful links I don't *want* to strip, though
[01:24:08] <Krinkle>	 There's still many ways to allow script execution, such as <img onload> and <a href=javascript:>)
[01:24:14] <mooeypoo>	 that's the problem. Otherwise I'd have just stripped it all
[01:24:18] <Krinkle>	 so parseHTML doesn't help much actually
[01:24:24] <mooeypoo>	 oh
[01:24:30] <mooeypoo>	 crap.
[01:24:30] <mooeypoo>	 :\
[01:24:32] <mooeypoo>	 So... I'll have to strip everything, then?
[01:24:40] <Krinkle>	 mooeypoo: Sounds like a design issue.
[01:24:46] <mooeypoo>	 Krinkle, it's an API issue
[01:24:47] <Krinkle>	 mooeypoo: Where is this? I think there's a simpler way
[01:25:00] <mooeypoo>	 Krinkle, the image extmetadata API responses 
[01:25:11] <mooeypoo>	 so, you have "Artist" and "Credit" and "License" etc
[01:25:28] <Krinkle>	 Which is ts
[01:25:31] <Krinkle>	 Which is text?
[01:25:33] <mooeypoo>	 It *should* contain artist = username+link to username profile in the username's native wiki etc
[01:26:07] <mooeypoo>	 and Credit has either text "Own work" or, more often than not, a link to credit page. For example, "http://foo.bar.com/image.is.from.here/" etc
[01:26:21] <mooeypoo>	 License is mostly safest, though again, it all comes from the template in Commons
[01:26:29] <mooeypoo>	 so you just trust users to fill it out properly, and that's not always the case
[01:26:44] <Krinkle>	 mooeypoo: None of them take html as input though, right?
[01:26:53] <Krinkle>	 text or wikitext?
[01:27:05] <Krinkle>	 if text then don't use escape orhtml, but just insert as text nodes
[01:27:12] <mooeypoo>	 Krinkle, I sent RoanKattouw_away and TrevorP|Away a case the other day where the "Artist" value was a huge html-filled output explaining some credit thing
[01:27:17] <Krinkle>	 if wikitext, the api module providing it should parse it for you and provide safe html
[01:27:31] <Krinkle>	 mooeypoo: I'll need an example
[01:27:35] <mooeypoo>	 yes, it's all text or wikitext, though someone could, theoretically, write raw <html> I think, in the template value, no?
[01:27:48] <Krinkle>	 I don't know this api, it's a new experimental extension that has questionable code quality 
[01:28:14] <Krinkle>	 mooeypoo: well, users can type anything anywhere, that's valid wikitext
[01:28:19] <mooeypoo>	 Krinkle, i sent you the crazy response I got 
[01:28:34] <mooeypoo>	 it's not representative, this doesn't happen *often* -- but this shows that it does happen
[01:28:38] <mooeypoo>	 hence my concren
[01:28:40] <mooeypoo>	 concern*
[01:28:46] <Krinkle>	 The letters "<script>" are valid wikitext to generate the html "&lt;script&gt;" that requires no escaping.
[01:29:10] <mooeypoo>	 <img> is legal though. <img onload=" ... "> stuff ?
[01:29:25] <Krinkle>	 how is <img> legal?
[01:29:27] <Krinkle>	 [[file:]] is
[01:29:41] <James_F>	 Krinkle: It's post-action=parse contents.
[01:30:03] <Krinkle>	 James_F: parsed by whom?
[01:30:07] <mooeypoo>	 Krinkle, the whole point is that wehave unpredictable API responses. I either escape it completely and lose some data (or have to do some annoying conditional flips to hope to parse different kinds of stuff) or we try and make sure that at least if there's crappy user-generated input, it's not ruining anything
[01:30:18] <James_F>	 Krinkle: api.php
[01:30:30] <Krinkle>	 There is no such thing as unpredictable API responses. There are crappy APIs though, but that can be fixed.
[01:30:43] <Krinkle>	 All user input is either text or wikitext. From meta data.
[01:30:44] <James_F>	 Reliable APIs querying unreliable content.
[01:30:48] <mooeypoo>	 ^^
[01:30:59] <mooeypoo>	 This API is reliably querying the commons template.
[01:31:06] <mooeypoo>	 The template is fed by users, who are unreliably putting data in.
[01:31:12] <Krinkle>	 Nothing anywhere on all of Wikimedia at this point, short of Parsoid, takes raw HTML as its input. 
[01:31:25] <Krinkle>	 So stripping is a lost cause.
[01:31:30] <mooeypoo>	 Okay, so maybe my fear is unwarranted.
[01:31:32] <mooeypoo>	 wait, what?
[01:31:34] <Krinkle>	 It should not be considered htlm unless it's from the parser.
[01:31:52] <Krinkle>	 at which point is safe.
[01:31:58] <mooeypoo>	 Krinkle, https://www.mediawiki.org/wiki/Extension:CommonsMetadata
[01:32:18] <mooeypoo>	 example response https://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&format=xml&iiprop=extmetadata&iilimit=10&titles=File%3ACommon%20Kingfisher%20Alcedo%20atthis.jpg 
[01:32:24] <mooeypoo>	 mind you, that's a sane response
[01:32:38] <mooeypoo>	 but, notice the value of "Artist" for instance
[01:32:39] <mooeypoo>	 <Artist value="<a rel="nofollow" class="external text" href="http://photo-natur.de">Andreas Trepte</a>" source="commons-desc-page"/>
[01:32:55] <Krinkle>	 That's wikitext parsed to html.
[01:32:57] <Krinkle>	 that's safe.
[01:33:06] <mooeypoo>	 okay, so the question is -- can I trust this to always be safe?
[01:33:31] <mooeypoo>	 Obviously, I'll use $.parseHTML to avoid the issues we discussed above, but can I append what I get without fear of it breaking the system?
[01:34:20] <mooeypoo>	 Krinkle, want a nicely INSANE response? check this out: https://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&format=xml&iiprop=extmetadata&iilimit=10&titles=File%3ACows%20in%20green%20field%20-%20nullamunjie%20olive%20grove03.jpg
[01:35:09] <mooeypoo>	 So, I'm not going to use "Permission" in there, but that kind of huge annoying html *can* appear in ANY of those fields
[01:35:34] <Krinkle>	 mooeypoo: In theory, yes. if CommonsMetadata interpets the parsed wikitext, extracts values, and doesn't misinterpret text as html or vice versa then yes. If that isn't eh case, it sure isn't something you shoudl worry about in visualeditor.
[01:36:01] <mooeypoo>	 so I should consider it always safe, albeit sometimes annoying
[01:36:05] <Krinkle>	 mooeypoo: However, it suffers from the same problem as {{Information}} on Commons: They can include block level elements. They're not text based or validated in anyway.
[01:36:21] <Krenair>	 ew format=xml
[01:36:52] <Krinkle>	 So I'd say, unless CommonsMetadata filters this out, it can't be used for anything useful at this point (which it could/should filter out, if it ever wants to be used to import to metadata repo in the future)
[01:36:58] <James_F>	 Krenair: Indeed.
[01:37:03] <Krinkle>	 however from quickly looking at the source code, I wouldn't trust it at this point.
[01:37:09] <mooeypoo>	 James_F, ^^
[01:37:14] <mooeypoo>	 :\
[01:37:40] <Krinkle>	 mooeypoo: James_F: I'm missing context though. Where do you want meta data to show up in VE?
[01:38:07] <Krinkle>	 Is there a commit or phab task I can look at?
[01:38:08] <mooeypoo>	 Krinkle, in the media dialog; we're changing the way it shows information so when the user SEARCHES for an image, they get results, they click a result and see a bigger image with info
[01:38:11] <James_F>	 Krinkle: We're going to show it in the media selection dialog.
[01:38:34] <mooeypoo>	 Krinkle, https://gerrit.wikimedia.org/r/#/c/161342/ but i need to edit this for safety and work on sanitizing values
[01:38:35] <Krinkle>	 What kind of fields?
[01:38:44] <James_F>	 Krinkle: https://phabricator.wikimedia.org/T78161
[01:38:55] <Krinkle>	 There's a very fine subset of fields that it extracts based on strict rules that dont include arbitrary wikitext content
[01:39:02] <Krinkle>	 Those are usable.
[01:39:29] <mooeypoo>	 Krinkle, eh, those are limited, though. Date (which btw also has an issue, but that's being fixed at least)
[01:39:29] <Krinkle>	 LicenseShortName is one of those.
[01:39:33] <James_F>	 Krinkle: They're usable enough.
[01:39:50] <Krinkle>	 LicenseUrl, AttributionRequired
[01:39:51] <mooeypoo>	 Sure. So is LicenseUrl, or supposedly so
[01:40:04] <mooeypoo>	 attributionRequired is boolean
[01:40:12] <mooeypoo>	 the user sees "yes" it doesn't help them much
[01:40:24] <mooeypoo>	 anyways, the idea was to show useful info. Description, Artist, Credit, License
[01:40:31] <mooeypoo>	 just like media viewer
[01:40:35] <Krinkle>	 Artist and Credit are useless. Half of Commons very stupidly puts ~~~ in there which means a million images are attributed to Mr. Talk
[01:40:45] <Krinkle>	 Not to mention the fancy images and colors and crap
[01:40:54] <marktraceur>	 "media viewer" "useful"
[01:41:05] <marktraceur>	 Oh, wait. I mean. Media Viewer is great.
[01:41:21] <mooeypoo>	 https://en.wikipedia.org/wiki/Domestication#mediaviewer/File:Cows_in_green_field_-_nullamunjie_olive_grove03.jpg
[01:41:27] <mooeypoo>	 ^^ they seem to do the same
[01:41:45] <mooeypoo>	 look at the details. See "License details" has the crazy html
[01:42:07] <Krinkle>	 mooeypoo: One thing you could do is, since safe to parse as html (but not useful to display as html), use .text() in jQuery to only take the text
[01:42:16] <Krinkle>	 For things like Author 
[01:42:20] <Krinkle>	 But that'll loose links
[01:42:21] <mooeypoo>	 Krinkle, yea that's what I'm trying to do
[01:42:23] <mooeypoo>	 indeed
[01:42:34] <mooeypoo>	 I did that (though I've used $() instead of the parseHTML which I should fix)
[01:42:40] <mooeypoo>	 but that also isn't good for Credit
[01:42:42] <Krinkle>	 I'm use MMV has some methods to parse the hell out of it and selectively take some html elements (like links)
[01:42:45] <mooeypoo>	 credit sometimes has html
[01:42:48] <mooeypoo>	 err html links i mean
[01:42:50] <Krinkle>	 which should be in CommonsMetadata instead
[01:42:57] <mooeypoo>	 like, a link to the actual source of the image
[01:42:59] <Krinkle>	 and will be if we're to use it to import into data repo.
[01:43:29] <Krinkle>	 mooeypoo: For description I'd also go with .text()
[01:43:30] <mooeypoo>	 okay.
[01:43:44] <Krinkle>	 I don't think we'll want to display even links in there at this point.
[01:43:51] <mooeypoo>	 Krinkle, yeah. I'll strip description. Main thing is Credit and Artist. It would be a shame to lose the links there if we already have them
[01:43:59] <Krinkle>	 Yeah
[01:44:18] <mooeypoo>	 I do check for a link in the credit, some images have "http://bla" stuff
[01:44:30] <mooeypoo>	 so if that's the case I make it a link with "Credit" as its text
[01:44:32] <Krinkle>	 mooeypoo: Credit should be slightly better (though it fallsback to Artist) since various templates take an explicit text-only attribution= parameter
[01:44:39] <Krinkle>	 whih I'm hoping is waht CommonsMetadata looks for
[01:44:50] <mooeypoo>	 the problem there is that it doesn't recognize cases where users put in "This is from <a href='http://bla.com'>bla.com</a>"
[01:44:53] <mooeypoo>	 which happens
[01:45:13] <Krinkle>	 mooeypoo: Hm.. "Credit" makes it no longer visible/readable where the credit is from though
[01:45:33] <Krinkle>	 eople would have to follow it to find out (or however via status bar, which is poweruser-only, ux wise nonexistant)
[01:45:38] <mooeypoo>	 Krinkle, this only happens if I have a link alone
[01:45:45] <Krinkle>	 mooeypoo: Yeah
[01:45:53] <Krinkle>	 mooeypoo: coudl do < ahref =url>url</a>
[01:45:54] <mooeypoo>	 which people need to follow anyways to see what it says
[01:45:57] <Krinkle>	 and trim with css
[01:46:02] <Krinkle>	 ellipsis
[01:46:19] * mooeypoo defered to the design team and TrevorP|Away for that decision
[01:46:21] <Krinkle>	 or href=url>hostname</a>
[01:46:43] <Krinkle>	 var a = <a href>; a.hostname; // Yay for built-in url parsing in modern browsers
[01:50:59] <wikibugs>	 3VisualEditor, VisualEditor-EditingTools: Typing inside a dialog while keeping the link inspector open, types the letters in CE  - https://phabricator.wikimedia.org/T78026#845371 (10Jdforrester-WMF) p:5Triage>3Normal
[01:51:16] <wikibugs>	 3VisualEditor, VisualEditor-ContentEditable, VisualEditor-EditingTools: Trim selections with whitespace on the end when annotating - https://phabricator.wikimedia.org/T53023#845374 (10Jdforrester-WMF) 5Open>3Resolved
[01:52:40] <mooeypoo>	 Krinkle, I have to run. I'll come back later and work on at least stripping as many of the fields as can be stripped
[01:52:45] <mooeypoo>	 and properly with $.parseHTML
[01:52:47] <mooeypoo>	 thanks!
[02:02:36] <Krenair>	 James_F, that feels like a dupe
[02:02:44] <James_F>	 ?
[02:03:56] <Krenair>	 but I can't find what of
[02:04:02] <James_F>	 Ha.
[02:06:05] <Krenair>	 James_F, https://phabricator.wikimedia.org/T75675 ?
[02:06:57] <Krenair>	 maybe not quite. no link inspector
[02:07:12] * James_F nods.
[02:09:24] <wikibugs>	 3VisualEditor, VisualEditor-MediaWiki-References: The reference dialog should disable the "Apply changes" button until a change is present - https://phabricator.wikimedia.org/T76928#845386 (10Jdforrester-WMF)
[02:12:44] <wikibugs>	 3VisualEditor, VisualEditor-ContentEditable, VisualEditor-EditingTools: Trim selections with whitespace on the end when annotating - https://phabricator.wikimedia.org/T53023#845387 (10Jdforrester-WMF)
[02:26:32] <wikibugs>	 3VisualEditor, VisualEditor-MediaWiki, OOjs-UI: Replace and Replace all buttons are clipped in VisualEditor when using the OOjs UI MediaWiki theme - https://phabricator.wikimedia.org/T78042#845405 (10Jdforrester-WMF)
[02:26:34] <wikibugs>	 3VisualEditor, VisualEditor-MediaWiki-Templates, OOjs-UI: Parameter entries aren't indented in the transclusion dialog's booklet layout in VisualEditor when using the OOUI MediaWiki theme - https://phabricator.wikimedia.org/T78321#845406 (10Jdforrester-WMF)
[02:26:36] <wikibugs>	 3VisualEditor, OOjs-UI: "+" icon in VE transclusion dialog missing in MediaWiki theme - https://phabricator.wikimedia.org/T78177#845407 (10Jdforrester-WMF)
[02:26:38] <wikibugs>	 3OOjs-UI: Scrolling elements into view does not work in most cases - https://phabricator.wikimedia.org/T73609#845409 (10Jdforrester-WMF)
[02:26:39] <wikibugs>	 3VisualEditor, VisualEditor-MediaWiki, OOjs-UI: Vertical height of panel controls is too low in MediaWiki theme - https://phabricator.wikimedia.org/T78031#845408 (10Jdforrester-WMF)
[02:26:40] <wikibugs>	 3OOjs-UI: Update checkbox styles in MediaWiki theme to latest design spec - https://phabricator.wikimedia.org/T78199#845413 (10Jdforrester-WMF)
[02:26:42] <wikibugs>	 3VisualEditor, VisualEditor-MediaWiki, OOjs-UI: Need for a muted destructive state for buttons which are destructive but not important workflow items in the OOjs UI MediaWiki theme - https://phabricator.wikimedia.org/T78040#845410 (10Jdforrester-WMF)
[02:26:43] <wikibugs>	 3VisualEditor, VisualEditor-MediaWiki, OOjs-UI: Checked state of checkboxes looks off when zoomed in, in the MediaWiki theme - https://phabricator.wikimedia.org/T78036#845411 (10Jdforrester-WMF)
[02:26:44] <wikibugs>	 3VisualEditor, VisualEditor-MediaWiki, OOjs-UI: Disabled checkbox is almost indistinguishable from an enabled, selected checbox in the OOjs UI MediaWiki theme - https://phabricator.wikimedia.org/T78048#845412 (10Jdforrester-WMF)
[02:26:46] <wikibugs>	 3MediaWiki-Core-Team, MediaWiki-Vendor, UI-Standardization, OOjs-UI: Import OOJS-UI - https://phabricator.wikimedia.org/T76662#845414 (10Jdforrester-WMF)
[02:38:43] * James_F is going to assume that Roan's in-flight WiFi didn't work out, given it's been 1.5 hours since boarding. Oh well. :-(
[02:38:49] * James_F heads out.
[02:38:50] <James_F>	 Bye!
[02:55:47] <RoanKattouw>	 hah
[02:55:49] <RoanKattouw>	 James, you fool
[02:55:52] <RoanKattouw>	 It just took a while before we were able to take off
[04:11:32] <RoanKattouw>	 Urgh references are too damn complicated
[04:11:48] <RoanKattouw>	 I'm slowly relearning why InternalList is as complex as it is
[09:57:01] <wikibugs>	 3Mobile-Web, MediaWiki-ResourceLoader, MediaWiki-Core-Team: Introduce MediaWiki:Mainpage.css - https://phabricator.wikimedia.org/T78418#845621 (10Schnark) There might be more than one page, where the main page CSS needs to be loaded:  * Commons has different main pages depending on your language (e.g. [[https://...
[11:29:15] <grrrit-wm>	 (03PS1) 10Esanders: Prevent parent window scroll in modal mode using overflow hidden [oojs/ui] - 10https://gerrit.wikimedia.org/r/179598 
[12:35:35] <wikibugs>	 3MediaWiki-ResourceLoader, MediaWiki-Core-Team, Mobile-Web: Introduce MediaWiki:Mainpage.css - https://phabricator.wikimedia.org/T78418#845954 (10Edokter) Perhaps this can be solved by use of some keyword or link, making it more universally applicable in the long run, ie. [[css:MediaWiki:Mainpage.css]].
[17:17:36] <wikibugs>	 3VisualEditor: When I changed the website link in an infobox all other links got redlinks - https://phabricator.wikimedia.org/T78472#846206 (10rugk) 3NEW a:3rugk
[17:18:05] <wikibugs>	 3VisualEditor: When I changed the website link in an infobox all other links got redlinks - https://phabricator.wikimedia.org/T78472#846206 (10rugk) a:5rugk>3None
[17:30:32] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on svwiki: https://sv.wikipedia.org/?diff=29155982
[17:30:32] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on svwiki: https://sv.wikipedia.org/?diff=29155986
[17:30:32] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on frwiki: https://fr.wikipedia.org/?diff=109919603
[17:30:32] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on zhwiki: https://zh.wikipedia.org/?diff=33588380
[17:30:32] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on zhwiki: https://zh.wikipedia.org/?diff=33594857
[17:30:33] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on zhwiki: https://zh.wikipedia.org/?diff=33595201
[17:30:33] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on zhwiki: https://zh.wikipedia.org/?diff=33595941
[17:30:34] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on ruwiki: https://ru.wikipedia.org/?diff=67310775
[17:30:34] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on ruwiki: https://ru.wikipedia.org/?diff=67310873
[17:30:35] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on itwiki: https://it.wikipedia.org/?diff=69604535
[17:30:35] <wm-ve-needcheck>	 Corruption alert: visualeditor-needcheck on trwiki: https://tr.wikipedia.org/?diff=14910722
[17:52:18] <grrrit-wm>	 (03CR) 10Bartosz Dziewoński: "This is pretty!" [oojs/ui] - 10https://gerrit.wikimedia.org/r/179404 (owner: 10Prtksxna)
[17:59:20] <grrrit-wm>	 (03PS1) 10Bartosz Dziewoński: MediaWiki theme: RadioInputWidget tweaks [oojs/ui] - 10https://gerrit.wikimedia.org/r/179624 
[18:01:43] <grrrit-wm>	 (03PS1) 10Bartosz Dziewoński: demo: Use 'mediawiki' theme by default [oojs/ui] - 10https://gerrit.wikimedia.org/r/179625 
[18:06:41] <grrrit-wm>	 (03CR) 10jenkins-bot: [V: 04-1] MediaWiki theme: RadioInputWidget tweaks [oojs/ui] - 10https://gerrit.wikimedia.org/r/179624 (owner: 10Bartosz Dziewoński)
[18:11:59] <grrrit-wm>	 (03CR) 10Bartosz Dziewoński: "This change added the .png and .min.css files. I don't think that was intentional, was it?" [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/178948 (owner: 10Bartosz Dziewoński)
[21:17:58] <grrrit-wm>	 (03PS64) 10Paladox: WikiEditor: Re add SVG [extensions/WikiEditor] - 10https://gerrit.wikimedia.org/r/151611 
[21:18:17] <grrrit-wm>	 (03PS34) 10Paladox: WikiEditor: Convert .css to .less and add Arrow SVG images [extensions/WikiEditor] - 10https://gerrit.wikimedia.org/r/151616 
[21:19:25] <Krenair>	 >> !!(function(){})
[21:19:26] <ecmabot-wm>	 Krenair: (boolean) true