[00:04:53] nkomura, about https://bugzilla.wikimedia.org/show_bug.cgi?id=22428 I think they're saying that syntax highlighting *on the page* for source code isn't highlighted anymore [00:05:02] not in the edit window [00:06:06] or rather, it's highlighted but broken because of the line breaks [00:06:12] oh [00:07:21] my bad [00:07:26] i'll take off my comment [00:11:29] btw, who is building a javascript wikitext parser? [00:12:52] nkomura: if a professor introduces himself as Yoko Kubota, what is the polite way to address him? [00:13:22] or her, for that matter [00:13:38] Professor Kubota would be appropriate [00:14:00] I have this vague impression that Japanese names are typically reversed [00:14:00] unless she asks you to address her by her first name [00:14:11] right [00:14:26] Yoko is the first name and the latter is the last name [00:14:56] ah, so Yoko is a female name? [00:14:56] are you working on your japanese for your trip? [00:15:17] I haven't learned anything new, though I remember a little from school [00:15:33] Ohayo Gozaimasu, Nan desu ka, Watashi wa pinku zo desu? :) [00:15:35] *werdna hides [00:15:56] ohayo werdna [00:16:13] I know this, ohayo gozaimasue [00:16:26] minus the e [00:16:53] ;) [00:17:10] adam_miller: did you commit a spinner that spins indefinitely? [00:17:19] Dozo yoroshiku [00:17:21] ha! I remember that [00:17:49] nimish_g: no? [00:18:38] werdna: pretty good! [00:18:43] nkomura: how does one say "Thank you" in japanese? [00:18:59] arigatou gozaimasu (polite way) [00:19:05] arigatou (casual way) [00:19:19] My european travels taught me that that is one of the more important words to learn :) [00:21:42] ;) [00:22:38] nimish_g: can we review the fix for preserved formatting? [00:23:01] it's on prototype [00:23:12] prototype or deployment? [00:23:44] prototype...remember Roan has deployment locked [00:24:16] right [00:25:15] did the fix behave the way you guys intended? [00:27:51] mostly [00:27:58] we can't prevent drag and drop [00:28:45] I'm still looking into the adding random linebreaks issue...I went through a few things and I'm pretty sure it's something in our code doing it, I'm trying to disable text manipulations we do bit by bit to find where it is [00:30:31] when i insert a formated text such as page title, the text is enlarged before the formatting is stripped [00:30:36] do you see that? [00:36:36] that happened earlier today on enwn [00:41:15] MC8: do you mean the formatting is preserved in the editor? [00:42:03] yep [00:42:16] yeah we are working on the fix for that [00:42:27] getting close, but it has a side effect [00:42:47] that's what nimish_g and TrevorParscal are looking at right now [00:43:29] TrevorParscal: any idea what would cause every single element in the DOM to get a font-size applied? [00:43:32] MC8: basically, just before something is pasted we mark existing things, then after the paste we strip out tags that weren't marked [00:43:59] the distance in time between the actual paste event and stripping can be visible [00:44:02] i just caused it twice by redo-ing several times in quick succession in firefox [00:44:25] meaning you see, for just a split second, the formatted version of your paste, and then it gets torn down to the stripped version [00:44:49] adam_miller: that sounds strange [00:45:04] ctrl + and ctrl - adjust font size [00:45:13] they are on the other side of the keyboard [00:45:27] is it in the actual CSS? [00:45:46] inline styles [00:45:56] font-size: somethign [00:46:15] i just got it stuck in an infinite loop of increasing the font size and had to force quit firefox [00:46:25] so bizzarre [00:47:22] try opening an edit page in firefox and before you do anything else hit ctrl+shift+z, see if it happens for you [00:49:32] NVM, web developer extension was doing it [00:52:44] you web developer extension sounds possessed. [00:57:12] ewww [00:57:31] look at the usability wiki [00:57:45] the tabs seem to have a black upper border [00:57:59] (inactive tabs with vector) [00:58:17] ah never mind [00:58:59] wow changing the zoom is weird [00:59:32] anyway [01:07:18] *werdna got distracted reading the Wikitravel article on Japan [01:08:32] This selenium code for the PagedTiffHandler looks really good [01:08:39] werdna: are you flying into kansai airport ? [01:08:53] hi Ryan_Lane! [01:08:58] nkomura: hi :) [01:09:56] RobH: Did you get a chance to check out telsa? [01:09:57] nkomura: yes [01:10:25] Ryan_Lane: i was typing the same question :) [01:10:26] nkomura: They arranged a shuttle for me to get there, but I'm hoping I can pick up a Shinkansen back. [01:10:31] heh [01:10:52] werdna: i was going to send you NYT's article about ramen shops in tokyo [01:11:24] but i will look for good readings for kyoto/osaka [01:11:24] I don't think I'll make it to Tokyo [01:12:01] brb [01:19:43] werdna: how long will you be in kyoto? [01:20:11] if you take shinkansen from kyoto to osaka, it only takes 15 minutes [01:22:00] Ryan_Lane: do you need a better privilege to reconfigure the disk of tesla? [01:23:12] nkomura: from Monday until Friday [01:23:18] Monday night until Friday night, that is [01:23:19] nkomura: Well, I have console access to the system, but it is browser based, and the keystrokes I need to send get captured by the browser. [01:23:43] nkomura: So I can't get to the raid configuration, or the ESX console [01:25:33] does RobH have a way to configure it remotely without key strokes captured? [01:25:48] he has physical access right? [01:26:09] if he goes to the datacenter, yes [01:26:32] if there is a way for me to do it remotely, I'm more than willing [01:27:57] i will ask RobH via email what would be the best way to go about it [01:31:08] ok [01:31:19] *werdna disappears to construct a stir-fry [01:31:23] I'm sure its possible to send keystrokes that would normally be captured [01:31:26] ask werdna [01:31:32] when he undisappears [01:34:10] nkomura: do you have the bug ID for the text formatting? [01:34:34] nimish_g: it's 22394 [01:34:43] see http://etherpad.com/BIWzOkAfa0 [01:35:44] werdna: so i suggest you find a time to hop on shinkansen (nozomi) and visit osaka and kobe [01:35:47] that'd be fun [01:36:18] werdna: nozomi is the fastest of all three models (nozomi, hikari, and kodama) [01:38:57] nkomura: ok I sent an email to Calcey [01:44:33] nkomura: I don't know how much of my time will be taken by the university [01:44:45] hopefully the last day will be up to me, and I leave at 8pm [01:50:48] *werdna returns with his stir-fry [01:50:53] something of a failure, I think [06:31:00] this optional survey for when you leave the beta looks suspiciously like a non-optional survey [06:31:21] I have to manually choose 'other' for browser & OS, and blank out my res if I don't want you to know? [06:31:51] and then you'll have a nice fat useless stat [07:01:14] s/and then you'll have/and _now_ you have/ [10:18:22] hmm, is the tabindex fix deployed yet ? [10:18:50] because on my Safari it goes from the textarea to the "minor edit" box, instead of to the editsummary [10:21:01] Doesn't Safari have a DOM inspector? Could you check whether the iframe has tabindex="1" ? [10:21:25] (also please report the tabindex attributes of the summary box and the minor edit box) [10:32:17] yes it has tabindex 1 [10:32:38] And the other ones? [10:32:53] wpsummary also has 1 [10:33:12] that can't be right :D [10:35:25] It is legal, but perhaps Adam didn't account for it, lemme look at his code [10:38:31] oh look, it's RoanKattouw [10:43:40] so in the editform, is the iframe translated back to the wpTextbox1 before form submit ? [10:44:00] Yes [10:44:10] k. [10:44:15] It seems Mike-lifeguard's user scripts interfered with that somehow [10:44:30] *thedj looks at ways to fix all the autoedit scripts [14:49:52] thedj: Does Safari's DOM inspector allow you to change stuff in the DOM? Could you change the tabindex on the summary box to 2 and see if that fixes your issue? [14:58:14]

catrope * r62247 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): [14:58:17]

UsabilityInitiative: (bug 22379) Cursor moves to beginning of inserted text on [14:58:18]

non-IE browsers. We're now back at the previous behavior where the cursor is [14:58:20]

placed at the end of the inserted text, or selects part of the inserted text in [14:58:22]

certain cases [15:00:38] hi RoanKattouw [15:00:59] Morning [15:01:16] how did the driving test go? [15:01:32] It was canceled due to the snow, AGAIN [15:01:40] That's the third time this very same test has been canceled due to snow [15:01:45] that sucks [15:02:08] i'm puzzed with the comment from CIA-78 [15:02:23] how could it start behaving differently [15:02:36] Basically I implemented the behavior Parul asked for [15:02:43] I'll stage it on deployment prototype in a minute [15:03:02] RoanKattouw: i'll check [15:03:39] RoanKattouw: yes, that does fix it. [15:03:55] adam_miller: .append( $( '' + mw.usability.getMsg( 'wikieditor-loading' ) + '' ) --> why not use .text()? Cleaner and has the side effect that an evil value for the wikieditor-loading message doesn't blow stuff up :) [15:04:08] Not urgent though, I'm fine with deploying it that way, personally [15:04:10] thedj: OK thanks [15:04:48] RoanKattouw: I'm going to hold off for now, i think paru is going to have me get rid of all that code today anyway [15:05:05] RoanKattouw: nimish wanted to install his fix for formatting yesterday [15:05:30] nkomura: Yeah I read the logs [15:05:38] The way it's set up now is kinda inconvenient [15:05:55] I'll send an e-mail with instructions for updating [15:06:07] will you stage nimish's fix on deployment as well [15:06:16] no bug report came back on that [15:07:03] I'll stage everything we have so far on deployment [15:07:11] Including the commits Adam and I made 5 mins ago [15:09:27] thanks [15:09:34] Done [15:10:37] walking to my office, i'll be back on in 30min [15:15:15] RoanKattouw: did you have a chance to look at email message from howie from last week? [15:15:28] The one about the weird optin numbers? [15:15:42] right, the monthly number did not look right [15:15:53] i do need those numbers for the report to stanton [15:16:21] I can't explain it, really, I see those numbers in the DB [15:16:40] All I can think of is that maybe the DB is faulty or it updates if someone opts in-out-in or something [15:16:44] I'll investigate later [15:16:49] How urgent is this? [15:17:13] it is urgent as i will need to finish the report today [15:18:14] RoanKattouw: my availability is limited today, so i will ask trevor to make a call on deployment of bug fixes today [15:19:28] OK [15:26:57] did you guys have inspiration for the line break bug? [15:27:00] https://bugzilla.wikimedia.org/show_bug.cgi?id=22398 [15:27:10] https://bugzilla.wikimedia.org/show_bug.cgi?id=22428 [15:27:24] people are annoyed by these issues a lot [15:29:04] Sorry, that's one of those things I don't have much of a clue about [15:29:50] Wait a minute... [15:31:00] Aha! [15:31:20] nkomura: The numbers are all wrong because there's something wrong with the toolserver copy of the prefstats table. The table on the cluster does look sane [15:31:22] I like that "aha" ;) [15:31:54] I'll ask the toolserver folks to fix that if they can; if they can't do that in a few hours' time I'll export the cluster tables and run my queries on them [15:34:01] thanks RoanKattouw, exporting cluster tables sounds like a daunting task [15:34:58] Not really [15:35:09] I have scripts that automate all that for me [15:35:17] There's no way I'm gonna export 812 tables by hand :) [15:36:01] *RoanKattouw decides he doesn't wanna wait for toolserver folks and does the export thing anyway [15:38:51] nkomura: To illustrate the size of the discrepancy between the toolserver and the cluster, here's the same query (# of users that opted in before 12/31/09) run on the toolserver (above) and the cluster (below) [15:40:04] http://mediawiki.pastebin.com/m31324c98 [15:40:51] ?! [15:41:12] the difference is double digits? [15:42:04] OMG it's even worse: http://mediawiki.pastebin.com/m4599f950 [15:42:12] Those queries say "count the number of rows in prefstats" [15:42:27] So the toolserver is missing almost 400k rows [15:43:40] And that's on enwiki alone [15:43:41] RoanKattouw: file a bug on jira plz [15:44:05] RoanKattouw: or poke river to fix it. he's payed to do that now :) [15:44:09] Daniel_WMDE: OK. I figured I'd ask in #wikimedia-toolserver in case it could be fixed quickly, since I need that data today [15:44:16] i bet all stats are affected by this discrepancy [15:44:34] I've already exported it on fenari so I could scp it over and import it into my user DB [15:44:46] if we are missing rows, then yes, definitly [15:45:09] nkomura: Only the /optin stats though [15:45:15] The other stats are based on another table [15:45:17] RoanKattouw: make sure river notices. a high prio jira ticket should also work [15:45:26] I pinged him in #wikimedia-toolserver [15:45:41] RoanKattouw: k [15:46:25] RoanKattouw: that's good if he notices, but jira is good so it doesn't get lost :) [15:46:34] Yeah [15:46:36] I'll file it there later [15:46:43] First I need to actually get my stats [15:54:34] Daniel_WMDE: Could you run SHOW INDEXES FROM prefstats; on the toolserver's enwiki DB and pastebin me the output? [15:54:42] s/INDEXES/INDEX [15:57:31] RoanKattouw: http://erxz.com/pb/23417 [15:58:01] Hm looks sane. Thanks anyway [16:00:34] nkomura: YAY! http://toolserver.org/~catrope/optin-20091231/all.total [16:01:53] Hm this did have the side effect of publishing optin/out statistics for private wikis as well [16:02:18] I think that's not that big a deal since it's aggregate numbers anyway [16:02:45] *RoanKattouw regenerates the other statistics [16:09:51] RoanKattouw: I'm looking into our remaining undo/redo problems - is there anyway to access cursor position in the iframe? [16:10:17] RoanKattouw: congrats! which are the private wikis? [16:10:17] Not really, BUT [16:10:26] nkomura: officewiki, board wikis, etc. [16:10:32] morning [16:10:37] adam_miller: Presumably all you want is save/restore? [16:11:26] RoanKattouw: it should be minimal, please mention it in the email to howie so that he knows [16:11:32] guillom: morning [16:11:33] adam_miller: ... because we already have context.fn.saveSelection() and restoreSelection() for IE, you could refactor that to work in all browsers and support getting the selection object as well [16:11:34] yeah, hoping we could store the cursor position with the snapshots of the contents in each history state [16:11:42] nkomura: OK will do [16:12:03] adam_miller: Yeah so if you look at saveSelection() and restoreSelection() you'll see that they really just save a selection object that .select() it [16:12:13] RoanKattouw: the total number seems lower [16:12:14] It's IE specific because we currently only need this behavior for IE [16:12:22] nkomura: I'm still regenerating stuff, please hold [16:12:29] k [16:13:33] But you could refactor that somewhat so we have a generic function that returns a selection object (TextRange for IE, Range for Firefox) and one that you pass such an object and restores it (.select() for IE, a bit more magic for Firefox, will write that up in a pastebin on request), then rewrite the current save/restore implementation to just call those functions if($.browser.msie) [16:15:26] adam_miller: --^^ some comments about save/restore in here in between stuff [16:15:37] yeah i saw them, thanks [16:15:59] you gave me some ideas, which i'm now going to explore [16:16:10] OK [16:16:50] Daniel_WMDE, others: Filed toolserver issue as https://jira.toolserver.org/browse/TS-508 [16:18:29] nkomura: I've regenerated the stats for July 31, Aug 31 and Sep 12, they look sane: http://toolserver.org/~catrope/optin-20090831/all.total [16:18:40] thanks [16:18:41] Others are coming in, each run takes a few minutes [16:19:08] great [16:19:16] i look forward the final output [16:19:35] i'd like you to run the daily stats later this week [16:19:39] You may have to click refresh before the new numbers show up, I have to [16:19:49] Sure we can set that up [16:19:57] *RoanKattouw wonders whether toolserver users can use cron jobs [16:20:45] 8/30 number looks about right [16:21:12] I have 7/31, 8/31, 9/12 and 9/30 now [16:21:28] Note that the 7/31 file is all zeroes because the first entry was at 8/6 [16:22:49] roger [16:26:50] Coolness: http://toolserver.org/~catrope/optinlist [16:27:11] (didn't update 11/30 and beyond, obviously) [16:30:49] 12/31 jumps up though [16:30:53] Yeah my mistake [16:30:56] It's regenerating now [16:31:06] (I forgot to set a cutoff date there) [16:33:51] OK it's done, summary @ http://toolserver.org/~catrope/optinlist [16:35:40] thanks [16:36:20] this is great [16:38:14] so the first column is vector in and the second is vector out [16:38:33] third and the fourth are for TB in and out right [16:39:16] ? [16:41:13] Yes [16:41:33] the growth in january is healthy [16:49:32] *RoanKattouw_away goes out to get dinner [17:26:58] RoanKattouw_away: what are saveSelection and restoreSelection used for in IE currently? I want to make sure what I'm doing isn't breaking anything [17:37:23] adam_miller: Saving and restoring the selection at random times to prevent IE from messing stuff up [17:37:33] hahahaha [17:37:47] Basically whenever you open a dialog the iframe loses focus and when focus is restored, IE forgets what the selection was and puts it at the start of the article [17:38:23] ok, cool. well I'll just be careful, and then poke at IE for a while after i'm done to make sure I dont see any selection forgetting [17:39:26] Cool [17:39:37] I have to leave again in 5 mins, I'll be back in 45 mins or so [18:09:09] RoanKattouw_away: when you get back...we were thinking to solve some of the random linebreak issues that we should have either an invisible textarea or invisible iframe where we can execCommand("paste") and then insert the entire contents of the textarea/iframe into the current cursor position [18:09:26] don't know if textarea takes execCommand tho [18:09:56] it looks like it might in IE, but doesn't look like FF does it [18:31:33] hello people [18:32:14] hi Trevor [18:32:58] thedj: thanks for helping out with that en.wp script stuff [18:44:35] nimish_g: Interesting... I have no idea what execCommand() is though :D [18:45:18] adam_miller: Based on thedj 's report your tabindex fix does not work properly in Safari because the iframe, the textarea and the summary box all have tabindex=1 [18:45:24] once upon a time MS decided this is something DOM objects can do...they can execute commands. later, when mozilla and others took their editable iframe idea, they kept this convention. I don't know how much they backported tho [18:45:26] (that right, thedj ? ) [18:46:04] nimish_g: OK, so why not throw an invisible textarea into the iframe and execute the command on that? [18:46:15] If there is this requirement of being inside a content-editable... [18:47:13] oh it's only for sure supported in content-editable iframes. I'm not sure if textarea has it or not outside of IE [18:48:27] RoanKattouw: that was my proposal [18:48:48] RoanKattouw: my idea yesterday is that we have a 2nd not visible iframe with content editable [18:49:06] and then we intercept the paste, execute the paste on the empty not-visible iframe [18:49:20] TrevorParscal: the second iframe has to have styling similar otherwise weird fonts get put in [18:49:21] then process the paste, then copy it into the visible iframe [18:49:41] nimish_g: no, we can do a .text() [18:49:50] ah ya [18:49:55] and then use the same text to html methods we use otherwise [18:50:25] We have to refactor textToHtml out then, it's inline in the .load() handler right now [18:50:33] this "offscreen" processing will make it so we don't have to classify everything in the $content document [18:50:43] RoanKattouw: indeed [18:52:47] nimish_g: I'll write an e-mail to the group about how anyone can update deployment [18:53:03] ok cool [18:53:21] I'm gonna check on the mystery cursor jumping bug [18:53:26] I'm trying to wrap my mind around this... https://bugzilla.wikimedia.org/show_bug.cgi?id=22401 [18:53:40] RoanKattouw: thank you [19:00:52] RoanKattouw adam_miller correct. All three elements have index 1, causing my tab to always go to "minor edit" which has index 3. [19:01:05] adam_miller: changing the tabindex of wpSummary to 2 solves my problem. [19:01:24] thedj: Yeah but we can't do that because wpSummary isn't always after wpTextbox1 (section=new) [19:01:24] RoanKattouw: when did you most recently update deployment? [19:01:39] Early this morning before you came in I think [19:02:00] TrevorParscal: no problem btw. :D [19:02:01] k [19:02:24] RoanKattouw: hmm, interesting. Makes you wonder how it worked at all before.... [19:02:45] thedj: Duplicate tabindexes are legal [19:02:51] I just talked to eugene about the iframe bugs on the strategy wiki [19:02:53] It's just Adam's code that seems to be handling them incorrectly [19:03:08] probably what confuses the browser is that the wikiEditor iframe is inserted dynamically, and the updating of the index doesn't account for that. [19:03:12] they were seeing allot of copy paste problems - which we already know about [19:03:17] RoanKattouw: shouldn't this return the elements in the order they appear in the DOM? [19:03:17] $j( '[tabindex]:visible' ) [19:03:40] I think it should [19:03:52] something interesting though, the last item of a series of list items will get a break between it's * and the text [19:03:55] thedj: Got Safari's debugger handy? [19:04:02] but the list items don't get breaks in them [19:04:05] RoanKattouw: no, at the library now :( [19:04:12] Bleh [19:04:31] thedj: you're seeing this in safari? [19:04:39] adam_miller: correct. Safari 4. en.wp [19:04:58] section edit btw. [19:05:02] RoanKattouw: http://prototype.wikimedia.org/d-en/index.php?title=User:WikiSysop&action=edit [19:05:02] not sure if that matters. [19:05:06] dod you see this error? [19:05:40] Blegh [19:05:41] *RoanKattouw fixes [19:06:22] Sorry, forgot about that one [19:07:11] adam_miller: I'm thinking maybe the a.tabIndex > b.tabIndex ? 1 : -1 is evil, it should be replaced with a.tabIndex - b.tabIndex to make the sort stable [19:07:25] Because if a.tabIndex == b.tabIndex, that'll return -1 and cause the sort to swap the elements [19:07:45] While if it returns 0, the sort will keep the original order [19:08:13] You know what, I'll hack that up on our deployment wiki and have thedj test it [19:08:33] *thedj will try to find VNC in order to test.... [19:08:44] You don't have Safari 4 at the library either? [19:08:54] nope. just FF and IE8 [19:09:02] RoanKattouw: that fixes it [19:09:14] Awesome [19:09:43] RoanKattouw: can you commit that? I've got a ton of local changes to that file i don't really want to remove or commit [19:09:55] Yeah I had the same thing this morning [19:09:58] I'll commit it real quick [19:10:01] thanks [19:11:53] RoanKattouw: something I've been thinking about doing, might fix this bug https://bugzilla.wikimedia.org/show_bug.cgi?id=22401 [19:12:04] we need to surround our
tags with

tags [19:12:12] OK... [19:12:17] what happens is, the cursor is at a
[19:12:26] and then you start typing [19:12:28] Yeah and crap gets inserted into the

before? [19:12:31] I've seen that happen [19:12:47] some browsers continue with using
tags, some make

tags, and others make

tags [19:12:54] which is causing this bug [19:12:59] OK we can p-wrap
s, but what about browser-inserted
s? [19:13:15] Or wait presumably that wouldn't be a problem because everything's in

s, right? [19:13:31] the browser will only insert
tags on shift+enter if we wrap the
tags at load with

tags [19:13:36] yes [19:13:43] so, I will make that patch and see if it works [19:14:01] *TrevorParscal svn up [19:14:16] I'm just committing something [19:14:28] I will up again when you commite [19:14:30] *commit [19:14:33] let me know [19:14:48] catrope * r62256 /trunk/extensions/UsabilityInitiative/js/ (3 files in 2 dirs): UsabilityInitiative: Fix tabbing fix, duplicate tabindexes were throwing it off [19:14:55] TrevorParscal: Permission to deploy that? http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62256 [19:15:24] RoanKattouw: yes, that fixes that bug where it makes everything have index 1 [19:18:22] OK deploying it then [19:24:37] thedj: Tab fix should be live now [19:41:56] I FIGURED OUT THE HAUNTED CURSOR!!!! [19:43:06] :) [19:44:05] YAY [19:44:08] What's going on? [19:45:13] RoanKattouw: I need some help with ranges [19:45:47] OK shoot [19:46:04] i can't seem to store an array of individual range objects, they seem to all be references to a single range object [19:46:24] Yeah in Firefox you need to use .cloneRange() I think [19:46:39] I started doing that and i still seem to be having problems [19:48:29] RoanKattouw: i'm using this in an attempt to return a snapshot of the current selection and store along with a history state http://pastebin.com/m4bc7b11b [19:49:40] adam_miller: Maybe just store a quadruple (startContainer, endContainer, startOffset, endOffset) instead? [19:49:52] And recreate a range from that when you need to [19:56:44] TrevorParscal: If we wanna do another fix deployment today I need to know within like 30 mins, I want to go to sleep in an hour [19:56:51] Alarm clock's set for 6:15 [20:00:19] RoanKattouw: which deployment? (Trevor's at lunch) [20:00:38] Recent bug fxies [20:01:28] Like the spinner covering the iframe, and more stuff, lemme peek what exactly [20:02:30] ok, if you wanna wait a little bit till Trevor gets back... (I don't know the testing/status of those fixes) [20:02:40] Yeah definitely [20:02:49] Naoko said Trevor calls the shots on deployment of things today [20:04:08] also, with regards to the haunted cursor...once in a while there's a BR inserted that says " type = "_moz" " [20:04:29] Hm [20:04:32] those seem to be throwing off offsets [20:04:39] I have seen _moz_dirty all over the place [20:04:49] yeah, but those attributes are set to "" [20:04:57] Right [20:05:07] this is
[20:05:14] which I actually see very infrequently [20:05:59] also, when I arbitrarily remove a

from the DOM, the cursor exhibits this jumping around behavior...as in you type, then it jumps back a spot or two [20:06:38] soo, I'm thinking if FF is randomly removing these BRs, it'll cause these jumps [20:09:14] RoanKattouw: i'm back [20:09:18] OK [20:09:29] TrevorParscal: I'm compiling a list of what's in the diff between wmf-deployment and trunk [20:09:35] awesome [20:09:42] I want to deploy all of it, basically [20:09:45] I'm interested in deploying everything that's stable [20:09:48] yes [20:09:49] Use svn diff | less on prototype to see the actual code [20:09:50] Rigth [20:10:01] undo is not stable yet though, so - there are *some* exceptions [20:10:06] adam_miller: any progress there btw? [20:11:03] TrevorParscal: yeah, i keep hitting snags, but still feel like i'm making progress [20:11:15] adam_miller: good stuff [20:11:26] adam_miller: are you enjoying this task? [20:12:44] TrevorParscal: i was about two hours ago :) [20:13:04] jk, it's still fun just has a healthy dose of frustration mixed in [20:14:04] frustration/challenge ratio is a good thing to keep in balance [20:21:03] TrevorParscal: http://pastebin.com/m56371fef [20:26:22] all of that looks good [20:26:44] OK could you look over svn diff | less on prototype and at that phase3 rev then? [20:26:52] I like the idea of someone having looked at code I deploy :) [20:28:47] lookin [20:30:23] all I see is a change on EditPage.php [20:30:50] ?: svn diff -r62243 | less [20:31:28] RoanKattouw: can i prevent delayedChange from firing when the change is caused by an undo or redo action? [20:32:03] TrevorParscal: Sorry wrong revid, grabbing the right one [20:32:03] sure [20:32:15] on line... [20:32:29] 350 [20:32:32] of wikiEditor.js [20:32:38] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62243 [20:32:44] oooh... [20:32:45] hmm [20:32:52] Oh you had the right revid [20:32:54] delayedChange is an agregate event [20:33:02] Yeah it's a change in wmf-deployment rather than trunk [20:34:03] adam_miller: Why do you want that exactly? [20:34:14] TrevorParscal: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62243 [20:34:43] RoanKattouw: to prevent weird hackery attempting to detect if a change was caused by an undo or redo event [20:35:12] I have this for detection right now: newHTML == context.history[context.history.length + context.historyPosition].html [20:35:32] That sounds sane [20:35:36] RoanKattouw: ok [20:35:46] I agree it's hackish but it's relatively sane [20:35:49] what if someone pastes in exactly what is already there? [20:35:56] TrevorParscal: So am I go to go ahead and deploy that whole bunch? [20:35:57] should i not care about that case? [20:36:04] RoanKattouw: yes [20:36:06] i guess i wouldn't really need to [20:36:38] just imagine, the user wouldn't be able to see a difference anyways right? [20:36:58] adam_miller: I was also thinking about the state saves [20:37:40] and we may be able to classify inputs, like characters, backspaces/deletes, other keys, mouse interaction [20:38:01] and the state should only get saved if it's different from the laste [20:38:04] *last [20:38:14] and only when changing inuput types [20:38:46] so, you can type a sentence of time, and that's 1 state, but if you type, then delete, then type again, that's multiple states [20:38:59] we save state on input classification change [20:39:04] what do you think about that idea? [20:41:42] TrevorParscal: I think that could work well, maybe save state on certain characters too, like a period, or a space, so if someone types up a paragraph without deleting or clicking out of the thing, they still have multiple levels of undo [20:43:46] yes [20:44:27] so there would be some classes of characters, and space, period, etc would be in their own [20:44:41] that way ....... doesn't mean 7 saves [20:44:52] but this. that. the other thing. is 3 saves [20:47:06] *werdna waves [20:48:08] OK all those fixes should be live on test now, please test (will do that myself too) [20:53:51] OK looks good except that the cursor jumps when pasting text [20:53:54] We can address that though [20:53:58] *RoanKattouw passes that issue to adam_miller [20:53:59] the 4th+ toc link just goes to the top [20:54:02] any clue on that? [20:54:10] Did you add a header by any chance? [20:54:17] i did nothing [20:54:20] just loaded thepage [20:54:25] and this is on my localhost too [20:54:27] Which page are you on? [20:54:30] can you reproduce [20:54:34] main page on test [20:54:43] main page on my local wiki... [20:54:45] That has 3 sections ^^ [20:54:56] 3rd+ i meant [20:54:56] sorry [20:55:03] counted section 0 [20:55:15] WFM [20:55:30] hmm [20:55:33] Oh after I add text it breaks [20:55:36] on my localhost its 2nd+ [20:55:57] Oh fail [20:56:08] We're removing :not(.wikiEditor) [20:56:14] Guess what doesn't have the wikiEditor class [20:56:17] TOC anchors! [20:56:27] ha ha [20:56:39] the highlighted stuff should [20:56:55] Huh you're right it does [20:56:57] WTF [20:57:05] hmm [20:57:18] Meh I have to totally fix that code anyway [20:57:36] any idea when this broke? [20:57:40] I think there's no other critical things for me to work on so I'll do that tomorrow when I have time [20:57:59] Probably around the time we started wrapping stuff in

s and I quickly hacked the highlighter for that [20:58:08] It needs to be smarter and split

s when it needs to [20:58:11] yeah [20:58:25] But that needs to happen anyway for Nimish's template code to not blow up completely [20:59:09] So I'll be taking a stab at that tomorrow when I have time (which is not a lot, e-mail about that underway) [20:59:25] RoanKattouw: why wrapping things in p's? [20:59:33] RoanKattouw: it's working in production though [21:00:04] *that*'s interesting [21:00:08] Oh wait [21:00:12] ? [21:00:20] Could it be that the offsets system is misinterpreting

[21:00:43] perhaps [21:00:46] that's new [21:00:47] nimish_g: Well the highlighter is too reluctant to break out of

foo{{bar}}baz

because

foo

baz

is illegal [21:01:34] nimish_g: ... so it needs to break up the

, and I haven't made it that intelligent yet. Will start doing that on the train tomorrow [21:01:38] all templates need to be spans with display:block [21:01:49] or not [21:01:52] in the case of inline stuff [21:01:57] probably just span [21:02:10] TrevorParscal: right now they're div's with display:inline [21:02:15] which is sort of a span anyways [21:02:21] yes [21:02:25] they should be span instead [21:02:30] i think [21:02:33] i could be wrong [21:02:38] might want to play with it [21:02:45] spans don't have the fun spacing layout properties tho, right? [21:02:57] Note that you can't put block elements inside a , that might be a limitation [21:03:12] aah ok, then ya they need to stay divs [21:03:24] b/c they open up and become block elements [21:03:32] RoanKattouw: for sure it's the

thing that broke the TOC [21:03:42] is there any quick fix in sight for that? [21:03:56] Yeah I'm poking at it [21:03:59] awesome [21:04:05] sorry, I know you need to go to bed soon [21:04:14] No worries [21:04:14] or... already... [21:13:09] OK got it, committing [21:13:24] awesome [21:15:18] TrevorParscal: Fact check: do we now *always* wrap
s in

s, even when the user messes around with it? [21:15:33] on load [21:15:35] we wrap them [21:15:49] Yes [21:15:50] the only way
will not be wrapped in

is within a p [21:15:58] like, multiple
s in a

[21:16:04] using shift+enter or paste madness [21:16:05] OK so loose
s that are direct children of the are not possible? [21:16:17] in theory [21:16:17] Because that's an assumption I'm kinda making right now [21:16:23] make it [21:16:28] and let's try and prove it wrong [21:17:03] catrope * r62263 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): UsabilityInitiative: Fix offset calculation to account for the fact that
s are now always wrapped in

s [21:20:42] TrevorParscal: Deployed on test, please poke and give me the green for cluster-wide deployment [21:20:52] If I don't get that green light in say 5 mins I'll shower and come back [21:21:09] k [21:21:11] lookin [21:21:34] hmm [21:22:10] http://test.wikipedia.org/w/index.php?title=Main_Page&action=edit [21:22:23] toc won't jump to sister projects for me on FF 3.6 [21:23:02] paste filtering doesn't seem active [21:23:06] is bits freaking out again? [21:24:51] Testing in Euroep [21:25:36] Confirmed [21:27:18] confirmed, you also see what I see, or bits is freakin out? [21:27:50] *RoanKattouw is an idiot [21:27:55] Running svn up before pushing stuff helps [21:28:01] ha ha ha [21:28:48] Try now [21:29:05] works [21:29:07] awesome [21:29:10] trying to break [21:29:14] go take a shower [21:29:17] I will try and break it [21:29:30] check in before you actually go to sleep [21:29:32] plz [21:29:34] OK [22:09:12] *RoanKattouw checks back in [22:09:56] hi [22:10:03] everything looks good [22:10:11] i've had the staff poking [22:10:43] OK so we wanna deploy? [22:10:53] It really just involves syncing a style version bump :D [22:10:58] *RoanKattouw <3 bits [22:11:01] ehm [22:11:02] http://en.wikipedia.org/w/index.php?title=Space_Shuttle_Atlantis&curid=28239&diff=343225164&oldid=342913594 [22:11:06] that can't be good though [22:11:21] WTF [22:11:34] Oh crap I think I may know why that happens [22:12:32] Actually no [22:12:36] It's not what I suspected [22:13:39] thedj: That's definitely browser-specific though, Firefox doesn't do this. [22:14:14] RoanKattouw: this is a VERY occasional user. not sure if he will answer when asked what his browser is. [22:14:27] I have a suspicion [22:14:39] Hm wait that wikiEditor-tab crap is IE-specific code :) [22:15:11] yes [22:15:17] that only happens on IE [22:15:24] other browsers cope with tabs OK [22:16:03] Oh right [22:16:07] I see why this happens [22:17:42] TrevorParscal: Try this http://pastebin.com/mfa32023 [22:18:19] TrevorParscal: Meanwhile, can I deploy what's on test now to the rest of the cluster, then go to sleep? [22:18:27] sure [22:18:31] what's this change do for us? [22:19:03] Well we insert , which gets entity-escaped because we use .text(0 [22:19:04] are we using the span for tab in all browsers? [22:19:09] No, just IE [22:19:12] ah [22:19:16] oh, so we need this too [22:19:22] can we include this in our push? [22:19:24] We convert stuff like <p> back to

but we forgot this one [22:19:26] Sure [22:19:31] awesome [22:19:32] But no one's tested it [22:19:38] sorry, i know you want to go to bed [22:19:48] And I'm not gonna fire up my VM and send my machine into near-swapdeath [22:19:49] pop this change on test and I will poound on it for a min [22:19:50] then we push [22:19:53] Will pop [22:19:58] I have mine ready [22:22:32] Pushed [22:24:05] testing [22:24:08] TrevorParscal: Fix should be on test. Try to insert tab characters on IE, then save, reload edit page and check for clean diff [22:24:18] k [22:25:14] There's also an issue where non-breaking space characters (as opposed to entities) get converted to breaking spaces [22:25:20] I'll tackle that tomorrow [22:27:36] TrevorParscal: Please also update the tech blog post after the push :) [22:27:54] RoanKattouw: clean diff [22:27:57] and I can't edit your post [22:27:59] I don't think [22:28:01] Be sure to add something like "UPDATE 22:27 UTC: Description of what you changed" at the botom [22:28:57] *RoanKattouw can edit others' posts [22:29:57] TrevorParscal: Try logging into the techblog and seeing if you can edit my post. In the meantime I'll deploy, OK? [22:30:28] yes [22:30:47] thank you [22:31:27] Done, please confirm [22:32:40] looking good [22:32:47] I will talk to some users in the office now [22:32:53] let them know things are a bit better [22:32:57] and solicit feedback [22:33:06] OK I'm running out [22:33:52] sleep! [22:33:53] :) [22:33:58] thank you SO much RoanKattouw [22:34:17] If you need more stuff staged on test, tell someone like werdna to merge the change into wmf-deployment, svn up on fenari, sync the changed .combined.min.js and increment the style version appendix in CommonSettings.php, then sync-common test. To push sitewide, sync CommonSettings.php [22:34:34] *changed .combined.min.js FILES [22:34:50] *sync-common test --> I mean run sync-common on srv124 [22:35:35] I swear he's secretly a machine [22:36:09] werdna: yes, he's probably a replicant [22:36:10] i agree :D [22:37:10] TrevorParscal: if you say that I may have to kill him [22:38:00] ha ha [22:38:01] brb [22:38:49] hi parutron [22:39:02] hi werdna how are you? what are you up to? [22:41:48] I'm well, parutron! Chugging away at work until university starts in March [23:20:54] Walking home. Back online in a bit