[14:30:05] thedj: Around? [14:31:39] thedj: I could use your help with that Netscape issue [14:32:19] yes. [14:32:46] what i did is that i set usability to raw mode, and then just started deleting scripts till it started working. [14:33:00] Right [14:33:05] then i restored all scripts, and checked if it really was ui.core that did the trick. [14:33:12] I wanna try something now [14:33:16] k [14:33:21] Could you point your old Netscape to http://prototype.wikimedia.org/deployment-en/ and verify that that crashes it? [14:34:47] yes crashes [14:35:28] OK [14:37:23] OK could you try http://prototype.wikimedia.org/deployment-de/ now? [14:38:05] nope, crashes [14:39:12] Meh [14:40:17] OK, now try http://prototype.wikimedia.org/deployment-fr/ [14:42:53] crash [14:43:42] WTF [14:43:51] I removed ui.core.js from the combined file [14:45:30] RoanKattouw: prototype isn't in combined mode. it's in raw mode. [14:45:53] Oh oops, forgot about that [14:46:09] Either way [14:46:24] I'm thinking of a solution that should work for Netscape and maybe even for Blackberry [14:46:45] Which is to defer loading of plugins.combined.js until we are sure the client's browser is supported [14:47:02] hmm, that's a can of worms though. [14:47:27] because webkit does weird stuff with load order at times. [14:47:48] Yeah one problem is we'd importScriptURI() it and presumably put it all the way back in the load order [14:47:59] But that'll apply to a future script loader as well [14:49:01] i wish i understood why that code crashes their JS parser... [14:49:15] i tried deleting parts of it, and i can't reproduce it properly. [14:49:16] Hm well [14:49:20] We could try upgrading jQuery UI [14:49:31] Let me do that on prototype real quic [15:15:40] OK, jQuery UI upgraded to version 1.8.2 [15:15:57] thedj: Could you try http://prototype.wikimedia.org/d-en/index.php?title=Main_Page&foo=bar ? [15:17:46] crashes :( [15:17:51] Meh [15:18:00] That's jQuery UI 1.8.2 , had hoped that wouldn't crash [15:18:20] i'm going trough old FF builds, trying to see if i can find the revision where it was fixed. [15:18:45] if i can find the fix, we might be able to better understand why the code triggers the crash, and we might be able to work around it. [15:18:54] Yea [15:19:24] In the meantime, I'm gonna try to write a makeshift scriptloader for this file [15:20:07] problem is that mozilla NB downloads from that long ago take 20 minutes to download :( [15:24:21] RoanKattouw: your best bet is to do a document.write [15:24:36] with conditionals .. just like google addwords works [15:25:07] this way you keep the same load order [15:25:23] Hmm [15:25:38] but you can't do document.write's outside of head, and outside of a primary because that breaks too on safari. [15:25:57] yea you have to do it in the head [15:26:25] importScriptURI() does this http://pastebin.com/P8Q2gQAf , how well would that work? [15:27:10] RoanKattouw: the problem is that you will have no idea when the script is available to other resources. [15:27:19] So I should be able to document.write() from a in the ? [15:27:33] That sounds easier than writing a makeshift mini script loader [15:27:45] thedj: Fortunately we already have the relevant code wrapper in mw.load() [15:27:51] So that's not much of a problem [15:27:56] But if I can avoid even that, that'd be nice [15:28:01] that "should" work... you just have to be a bit more careful and [re] test everything because some browsers do weird things like fire the dom ready where you bind it in the code .. not at the end of the script ( on dynamic includes ) [15:28:03] RoanKattouw: yeah, that should work. it's dirty, but i think it's the most reliable for this specific case. [15:28:42] mdale: Since this is only jQuery UI and there is no on-load or on-ready code calling it, I think it should be fine [15:28:48] oky [15:29:48] but your domReady stuff does use jquery ui things.. if you do a non-blocking importScriptURI() you can have your can ~sometimes~ get your ready code running before the jquery ui symbols are defined. [15:32:23] My domReady stuff doesn't use jQuery UI things IIRC [15:32:26] *RoanKattouw looks to make sure [15:33:09] Nope, only the reallyCreate function, which is only called when a toolbar button corresponding to a dialog is clicked [15:35:23] oky. .. you can use jQuery built in script loading call ... $j.getScript .. to wrap the binding of reallyCreate if you want to be very safe [15:40:58] Dude thank you so much for that tip [15:41:03] That makes my life a billion times easier [15:43:10] no problem ;) [16:02:49] OK awesome that works [16:20:19] thedj: OK please try http://prototype.wikimedia.org/de.wikipedia.org/Foo?action=edit in old Netscape now, should not crash and not display the usability toolba [16:20:22] *RoanKattouw grabs dinner [16:22:41] RoanKattouw_away: you are a king, works now. [16:48:17] Good [16:48:22] It's dynamically loading jQuery UI now [16:48:31] I wonder how Blackberry responds to that [17:09:28] RoanKattouw: mind taking a look at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/67559 and subsequent changes which fix the issues? [17:09:35] *TrevorParscal wants less fixme marks [17:09:44] OK [17:09:52] Hey do you know what the deal with Blackberry testing is? [17:10:06] I'm about to commit an elaborate workaround for Netscape 7 crashing on jQuery UI [17:10:19] And I'm curious to see if that works for Blackberry too [17:10:45] The workaround is essentially breaking all jQuery UI JS out into its own combined/min files and loading that on-demand [17:11:14] thats a good idea anyways [17:11:24] i mean, it's a much less used package [17:11:25] um [17:11:35] Yeah it's only the dialogs that use it [17:11:49] last time I had to test blackberry devices, I wandered around the office looking for people's personal phones to borrow [17:11:51] and all was fine [17:12:00] Right so we have no affected BB models in the office? [17:12:09] but there are some specific models we don't have right now that are causing issues [17:12:15] *TrevorParscal asks tomaszf [17:13:41] TrevorParscal, we got "blackberry is broken" feedback today, so not all is fine yet [17:14:04] TrevorParscal: but there are some specific models we don't have right now that are causing issues [17:14:18] Platonides: With "all was fine" he meant we don't own any of the affected models [17:14:29] in other words, the decides we HAVE are working, but not all are working [17:14:29] *RoanKattouw observes TrevorParscal talking to himself [17:14:46] it was supposed to be a quote... how do i quote in IRC properly? [17:14:54] blackberry should donate some devices to the wmf [17:15:04] TrevorParscal: blackberry should donate some devices to the wmf [17:15:13] Is what I get when I copypaste Platonides's line [17:15:24] damn colloquy [17:15:37] after all it is their fault [17:15:43] Yes [17:16:03] TrevorParscal: Got a planned deployment list at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/vectorfix , please review thoes [17:16:21] *TrevorParscal reviews [17:17:07] TrevorParscal: Marked that rev as resolved [17:17:32] thanks [17:24:35] *TrevorParscal is unsure about r67871's use of px font sizes [17:24:43] *TrevorParscal senses a wave of bug reports coming on [17:24:49] adam.... where you at? [17:25:17] He's not in here at least [17:25:26] I wasn't sure about that rev either [17:25:48] Note that this is a let's-deploy-this-today-after-lunch list so feel free to kick it off if Adam doesn't respond [17:26:19] k [17:26:24] i'm just looking into it [17:26:46] oddly, it scales, even with "Zoom text only" checked... in FF3.6 [17:26:51] does it scale with the page for you? [17:26:58] *TrevorParscal is going to need to check some other browsers [17:30:14] thedj: Where is your killEvent code again? [17:30:25] I haven't tried [17:30:38] When I see non-trivial CSS changes I just defer them to you [17:32:02] IE6 and IE5.5 users aren't going to like that rev.. but there's ways around that.. [17:32:13] I might just make a patch for it [17:32:55] RoanKattouw: http://en.wikipedia.org/wiki/MediaWiki_talk:Common.js#Change_to_collapsible_tables_code [17:33:23] Thanks [17:33:26] ha ha - he's clever [17:33:41] the label is never visible in browsers that won't scale the px text [17:33:44] so it's safe [17:33:54] I will add a comment so people don't have to wonder [17:39:15] Nice [18:03:07] RoanKattouw: should I bump w [18:03:14] w [18:03:14] w [18:03:17] wgStyleVersion, if I only changed the comment? [18:03:21] No [18:03:30] that's what I suspected [18:03:35] thanks for confirming [18:03:41] Change it only if it matters to you whether clients get the new version or the old one [18:05:20] RoanKattouw: r68011 [18:06:05] heh [18:06:25] *RoanKattouw mumbles something about an apostrophe in "don't" [18:06:51] gosh, it's just a comment! [18:06:59] haha [18:07:06] *RoanKattouw is our in-house language nazi [18:07:12] RoanKattouw, TrevorParscal is spelling deficient. [18:07:16] leave him alone. [18:07:18] And English isn't even my native language, go figure [18:07:26] I thought you were Canadian. [18:07:42] Only by inheritance [18:07:55] I have never actually set foot in Canada [18:10:27] *RoanKattouw offers apologies for his linguistic nazism to all those affected [18:10:48] I think the term Naziism is more offensive than the behavior... [18:11:21] he's from europe, he's allowed to say it... [18:11:32] or... something like that... isn't that the rule? :P [18:12:07] I'm from a formerly Nazi-occupied country, I'm allowed to joke about Nazis [18:12:59] *TrevorParscal will roll with that [18:17:40] TrevorParscal: I could use your input on a bug I'm tackling [18:17:46] k [18:17:48] #? [18:17:58] !b 19334 [18:17:58] --elephant-- https://bugzilla.wikimedia.org/show_bug.cgi?id=19334 [18:18:21] So what's going on is that if (width suggested by cols="" attr) < (actual width due to CSS), IE8 goes crazy and miscalculates stuff [18:18:46] The CSS change committed earlier mostly fixes this, but on wide windows in combination with low cols="" attrs, the bug still occurs [18:19:15] Now I see no problem with cols="5000" for instance, EXCEPT that it doesn't degrade gracefully when the CSS isn't applied [18:19:21] (e.g. text browsers) [18:19:40] So how justified is my reluctance to hardcode cols="5000" ? [18:19:57] *cary read "hardcore cols" [18:20:11] dont' hardcode it [18:20:16] set it with JS [18:20:26] Also, thedj has been looking at using $('#wpTextbox1').attr('cols', 5000); , but that causes an error in IE [18:20:35] hmm, there's still going to be people with CSS but no JS though... [18:20:43] hmm [18:20:46] That too [18:20:50] of course it does [18:21:05] ? [18:22:03] Works in Firefox, but that doesn't really help [18:22:06] so, the content before the box is causing this, in some way... [18:22:25] How do you figure that? [18:22:45] what's the difference between a normal edit page and a view source page? [18:22:52] the content before the textarea... [18:23:11] Wait you're saying edit is broken but view source is not? [18:23:22] other way around [18:23:27] iirc [18:23:31] No [18:23:33] Edit is broken [18:23:40] only when protected then... [18:23:43] View source cannot be broken this way because it has a disabled textarea [18:23:48] No, we're talking about different bugs [18:23:55] sorry [18:24:01] You're thinking about misplacement of the textarea on protected pages [18:24:11] What I'm talking about is weird scrolling when entering text [18:24:12] yes [18:24:16] sorry, ok [18:24:18] i see [18:24:38] Due to IE8 miscalculating stuff when the width suggested by the cols attr is less then the real, CSS-manifested width [18:25:28] right [18:25:30] ok [18:25:32] reading [18:25:40] Now unfortunately my IE8 debugger is totally broken [18:27:20] ok, so for graceful degredation [18:27:36] and compatibility with the preference of how wide to make the textbox [18:27:43] Yes, there's that too [18:28:29] I think we need to not be setting the textbox cols to something other than a sensible default (80x25) and allow the pref to override that.. [18:28:56] and then we should set the box width in PX based on the wikieditor's layout system [18:29:05] which we do when you resize the TOC anyways [18:29:26] what do you think? [18:30:00] Well that's the exact thinking that caused this bug [18:30:12] Typically, width: 100%; will be wider than cols="80" and IE8 goes berserk [18:30:22] (Except if you have a narrow screen) [18:31:02] what if the JS removes the cols attribute before sizing the box? [18:31:13] The JS doesn't size the box [18:31:15] CSS does [18:31:48] but without JS, the box never gets wrapped with the WikiEditor, and the CSS is never applied [18:32:02] and without wikieditor, there's no issue [18:32:04] right? [18:32:13] No, that's not true [18:32:18] k [18:32:20] The issue exists without WikiEditor as well [18:32:25] interesting [18:32:40] Previously, it was fixed (well except for the cols issue) in Monobook and WikiEditor re-applied the CSS that messed it up [18:34:13] i'm not able to reproduce [18:34:16] what's the trick [18:34:17] Having said that, I'm now leaning towards saying "not our fault" and moving on to the rest of my sizable TODO list [18:34:38] IE8, edit a long page like [[Jack Bauer]] or [[San Francisco]], change text halfway [18:34:48] Check textarea width pref beforehand [18:35:05] And make sure your screen is wide [18:35:13] k [18:36:02] check textarea width? and see that it's what? [18:36:25] Not huge [18:36:28] Double digits at most [18:36:36] default of 80 ok? [18:36:55] Yes [18:37:59] yeah, I can't reproduce still... [18:38:04] I think you should move on [18:38:10] make it as later or something [18:39:16] OK [18:39:20] I will try reproducing it later [18:39:24] Moving on to other stuff now [18:40:44] Since it looks like appropriate people are on the channel... [18:40:45] ok all these revs look good to me [18:40:55] TrevorParscal: Crap, we don't have a way to put sprite some bold/italic language icons but not others [18:41:05] Have you considered introduction of "expert mode" to WikiEditor? [18:41:09] TrevorParscal: So I'll need you to add http://commons.wikimedia.org/wiki/File:Toolbaricon_bold_%D0%96.png to the toolbar sprite and give me the coords [18:41:31] Or... maybe we do, hold on [18:41:52] i thought we did... [18:45:03] Well not yet [18:45:09] But adding that functionality looks easy [18:46:39] you adding it now? [18:46:49] Yeah nowish [18:46:51] Still gotta start [18:47:12] ha ha [19:46:30] TrevorParscal: Could you please review and mark as OK any remaining revs in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/vectorfix ? I want to deploy that batch around 1 or 1:30 [19:53:06] RoanKattouw: done [19:53:13] Thanks [19:53:26] So let's deploy them [19:54:16] Merging into deployment branch now [19:55:32] Oh God [19:55:58] Tim restructured DefaultSettings.php completely, any attempt to merge changes to that file between trunk and 1.16wmf4 is now hopelessly doomed [19:59:06] what is he doing with it? [19:59:29] DefaultSettings has only got wgStyleVersion bumps since [20:00:01] and previous to tim restructuring it was my bump for mw- prefixes [20:00:26] Yeah I was just merging a style version bump [20:00:30] Will apply that by hand instead [20:00:32] so increase styleversion in 1.16wmf4 and go with it [20:21:43] cary-lunch: Latin logos do not use italics in logo, Cyrillic do? Why? [20:22:03] Because Cyrillic italics in that font look a lot more awesome than Latin ones. [20:22:21] ask hannes when he's next on channel [20:25:02] OK merged and committed, took me long enough [20:25:10] Lemme throw this on prototype before I deploy [20:25:15] Ping howief [20:25:49] hello [20:25:53] Hello [20:26:12] what's up? [20:26:20] See my question above. Does UX team consider introducing anything like "expert mode"? [20:26:41] we're talked about it loosely, but haven't come up with anything definite [20:27:13] howief: another thing. Many people seem to be troubled about finding editing preferences [20:27:31] vvv: We should make direct-linking prefs sections possible with JS [20:27:39] more than what we discussed last week? [20:27:45] i.e. make Special:Preferences#editing work [20:27:51] (e.g., heading, special characters) [20:27:55] Most expirenced users would like to turn dialogs off, but not all are aware of its possibility [20:28:03] ah [20:28:30] maybe we should put a message on the new features page letting them know how to turn off specific features [20:28:38] right now it's all or nothing [20:28:39] TrevorParscal: Deployment candidate up at http://prototype.wikimedia.org/deployment-en/Main_Page?action=edit&uselang=ru . Please poke at it and give me the yes/no for deploying it when I get back in ~30 mins [20:28:52] k [20:29:03] TrevorParscal: (note that on the linked page, the italic icon is a sprite and the bold icon is a separate icon) [20:29:06] uselang=ru? [20:29:09] RoanKattouw: is that Netscape compatible in theory ? [20:29:17] thedj: Yes, would love verification [20:29:24] k, will double check [20:29:26] howief: I may try to discuss ideas of such an expert mode with community members [20:29:28] vvv: Someone requested new B/I icons for ru [20:29:35] looking good [20:29:48] RoanKattouw: yeah, I was one of requesters [20:30:07] that's an interesting idea [20:30:09] RoanKattouw: and it seems particularly bad for me, since it's write-protected ;) [20:30:21] Was a bit problematic as I tried to call it format-bold-Ж.png but that blew up TWN's SVN checkout [20:30:22] how different do you think "expert mode" is from the old toolbar? [20:30:40] vvv: Oh sorry about that. Change the title= in the URL to anything else [20:30:57] note that experts should be able to use the search & replace even if they want to disable the other dialogs... [20:31:20] You mean decouple S&R from the other dialogs? [20:31:22] howief: advanced stuff moved to top, added

tags, all dialogs disabled, headers displayed as buttons, not as combobox
[20:31:35] RoanKattouw, I would do so
[20:31:43] howief: expirenced users use the tab mostly as a tool of speeding up the typing
[20:32:07] vvv: can you clarify "the tab"?
[20:32:28] Not the tab, the bar, sorry
[20:33:13] we have put buttons on it we often use
[20:33:14] E.g. most users use link button to insert [[|]], since inserting those symbols means switchinh keyboard layout in many languages (including Russian)
[20:33:38] ah i see
[20:33:43] or characters that aren't at all at our keyboards
[20:33:58] That's what we have the specialchars widget for, right?
[20:34:26] vvv: so what you're saying is that the for russian wiki users, the old toolbar inserts the wikitext more quickly than if users had to type the wikitext in from the keybaord?
[20:35:09] RoanKattouw: nah, special chars are long way. Imagine you click internal link button about 50 times to insert link without switching keyboeard
[20:35:20] howief: that's what I understood from the feedback
[20:36:08] does US keyboard have [ and ] as direct keys?
[20:36:24] vvv: that's good to know.
[20:36:29] Yes
[20:36:43] We have []{}\| all as direct keys
[20:36:56] Because we're not using that space for accented characters
[20:37:02] TrevorParscal: Am I green to deploy BTW?
[20:37:07] you are
[20:37:22] thedj: Did that URL work in Netscape?
[20:38:37] howief: apparently is also wanted back by some users
[20:39:02] a toolbar customization dialog would be nice
[20:39:11] that way we could easily please everyboy
[20:39:15] Hm
[20:39:16] *everybody
[20:39:22] +1000 to Platonides
[20:40:17] vvv: so maybe in the meantime, we tell these users to go back to the old toolbar
[20:40:18] Starting deployment now
[20:40:20] howief: what about customizible toolbar?
[20:40:30] vvv: customizeable toolbar would be very nice :)
[20:40:43] we'll need to figure out where that sits in our list of priorities
[20:40:51] RoanKattouw: testing now
[20:41:03] I compiled openbsd sed just to find out that mac sed is based on freebsd's not openbsd
[20:41:04] now I compile freebsd and it segfaults when adding -i option
[20:41:05] howief: I may try to implement it
[20:41:13] probably due to my patching :(
[20:41:31] vvv: sure!
[20:41:43] Just tell me where to commit it when it's ready
[20:42:04] would you implement this on top of the new toolbar?
[20:42:24] New, I believe
[20:42:34] that would probably fit into extensions/UsabilityInitiative/WikiEditor/Modules
[20:42:38] vvv: Feel free to commit it any time as long as you don't break stuff. i
[20:42:43] RoanKattouw: crashes
[20:42:47] thedj: Crap.
[20:43:24] thedj: Oh that's probably AMW's fault. Let's try Wikipedia when I'm done deploying
[20:43:39] vvv: that sounds very intersting
[20:43:47] RoanKattouw: k
[20:43:50] what's AMW?
[20:44:31] Add Media Wizard
[20:49:03]