s instead of separating them by
s [18:30:56] And context.fn.htmlToText() doesn't convert

Foo

Bar

to Foo\nBar [18:30:59] Yet [18:31:17] ok, so shall i add that? [18:31:21] We do the same conversion for

for IE already, so you can mostly copy that, BUT [18:31:46] Obviously divs that we add ourselves need to be exempt [18:32:07] Fortunately, right now we only add empty ones at the beginnings of lines, so you may be able to cut the corner there [18:32:17] That's not a permanent solution of course but it'll do for now [18:33:28] alright i'll start workin on that [18:33:38] Cool [18:33:46] If you need any guidance poke me or Trevor [18:34:31] i'm back [18:34:32] sorry [18:34:49] was meeting with Neil, getting him caught up on the great JS2 battle of 2010 [18:35:57] haha [18:36:18] You wanted to talk to me? [18:36:29] (ignore the questions in my PM until you have time for them) [18:45:52] ok [18:46:24] so, adam_miller is working on the div conversion thing, and RoanKattouw is finishing up the IE

handling thing [18:46:56] TrevorParscal: What I'd like you to be poking at is serving each browser what they want [18:47:03] Has anyone taken a look at this? https://bugzilla.wikimedia.org/show_bug.cgi?id=22281 [18:47:06] We briefly touched on this yesterday [18:47:23] TrevorParscal: Yes that should be fixed now, asked Calcey to confirm [18:47:27] But it's weekend over there [18:48:00] RoanKattouw: yes, so doing

s for webkit,

s for IE, and
s for FF [18:48:12] Exactly [18:48:14] I think FF is happy with

s too actually [18:48:26] Yeah but it'll still create a mix [18:48:26] I noticed that it would just repeat whatever existed [18:48:29] Let's avoid that [18:48:31] Oh really? [18:48:39] FF is better than I give it credit for then [18:49:11] and IE and FF both do the shift+enter always makes
- just FF will only make a

or a

if you are already in one [18:49:28] OK well whatever's best :) [18:49:37] let me poke [18:49:42] As long as there's a remotely sane behavior for when we don't recognize the browser [18:50:27] TrevorParscal, adam_miller: Also beware that we're mostly poking at the same code, so commit early commit often, keep an eye on SVN and don't get pissed at merge conflicts [18:50:32] They will happen today [18:50:58] indeed [19:06:04]

catrope * r61674 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): UsabilityInitiative: Add a .prev() function to context.fn.traverser , need this for

handling in IE [19:15:09] RoanKattouw: how do I trigger htmlToText? [19:15:19] to test this code i've written? [19:15:27] From the console? [19:15:34] or in the browser [19:15:40] That's by far the easiest way, lets you test in Firefox with Firebug and all [19:15:47] It'll also be triggered on mousedown in the iframe [19:15:54] how from the console? [19:16:04] var context=$j('textarea').data('wikiEditor-context'); [19:16:11] oooo [19:16:18] context.fn.htmlToText("

Foo

Your favorite edge case here

"); [19:24:20] Whoo hoo [19:24:40] *RoanKattouw fixed the

== Header ==

at the start of the document edge case [19:26:07] adam_miller: BEWARE I'm gonna make a commit touching code in context.fn.htmlToText(), inside the $pre.find( 'p' ).each() function [19:26:17] have at it [19:27:55] CIA-64> catrope * r61676 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): UsabilityInitiative: Fix edge case where a document starting with

== Foo ==

would cause the header anchor to alternate between being added and removed [19:28:32] ok, so, even if I give the browsers what they want, we get into allot of crazy issues [19:28:52] Like what? [19:32:21] TrevorParscal: What kind of issues? [19:32:36] well, mostly chrome wants to nest things in divs allot [19:32:39] I'm playing with it [19:33:25] Nesting is not necessarily a problem [19:34:07] Do you mean it does Foo\nBar -->

? [19:34:29] 2 things [19:34:42] IE upon editing immediately starts nesting in P tags [19:34:47] WebKit with divs [19:36:25] in IE, the heading markers get placed at the begining of the document instead of being properly nested - http://img713.imageshack.us/img713/3019/picture1ie.png [19:37:18] playing with different starting formats [19:39:02] Yeah I know why the latter happens [19:39:09] Because you're feeding IE
s [19:39:14] It puts everything in a giant

[19:39:26] And you can't legally put

s inside

s, so we put them outside them [19:39:39] Try feeding IE

s instead of
s and see if that makes it happy [19:40:29] i'm trying a

content

approach [19:40:40] there are a few reasons this might work [19:40:42] hld.. testing [19:41:24] lol [19:41:37] If that does work, we need to kill a lot of my

handling code :D [19:43:03] nkomura: do you want normal screenshots or should I highlight the point of interest? (by darken everything else with 70% black) [19:44:40] the scan and mark functions are doing allot more work than needed [19:45:09] How exactly? [19:45:31] are there some edge cases where the heading tags need to be rebuild but the TOC does not [19:45:45] the TOC is now optimized to only do DOM modification upon an ACTUAL change [19:46:15] we could hash the markers we are about to place against previously placed ones, just as we do in the TOC, and skip the dom manipulation if they havn't changed [19:46:24] I guess [19:46:32] Highlight still doesn't do DOM manipulation if not needed [19:46:35] At least in theory [19:46:41] Well it'll tag stuff [19:46:45] yeah, it's doing allot more than is needed [19:46:49] That's probably what you're seeing [19:46:57] Yeah we should find a way to short-circuit it [19:47:00] With the hash thing [19:47:04] I'm watching it act on every delayedBind no matter what I press [19:47:13] even the up arrow [19:47:17] Yes [19:47:45] It traverses the DOM and tags each anchor as accounted for [19:47:55] Then it removes anchors that are unaccounted for and removes the tags [19:48:01] (the tags are classes on the

s) [19:48:01] strangely, IE7 is working much better than IE8 [19:48:05] *snort* [19:49:42] ok [19:49:52] the strategy that seems to work the best so far [19:50:09] using

line

and
for an empty line [19:50:27] RoanKattouw: i'm not seeing any problems with the htmlToText code as it exists. Am I blind? the console output seems to line up exactly with what's in the iframe in both safari and chrome [19:50:29] no browsers are feeling the need to nest everything in crazy ways [19:50:56] adam_miller: Including the

stuff? [19:51:05] AFAICT it currently doesn't handle that [19:51:06] and while IE still adds more P tags and WebKit still adds more

tags, it's not corrupting the crap out of the whole document when you edit a section [19:51:08] RoanKattouw: when I wrap some template text in a random div, all the stylization and wrapping seems to automacially happen around it. I'm digging around on this, but offhand do you know why that's happening? [19:51:13] Unless .text() magically accounts for divs in Webkit [19:51:21] nimish_g: What do you mean? [19:51:56] TrevorParscal: Cool, let's make that happen then. Requires eliminating some of my

compensation code though; look at the diffs [19:52:00] RoanKattouw: actually maybe i spoke too soon, i just spotted something off in safari [19:52:13] i see that [19:53:22] RoanKattouw: {{template|val1|val2}} then if I go $('#bob').wrap("

"); that template suddenly gets the template buttons and is collapsed etc. It makes me think we're scanning DOM elements when they randomly get created [19:54:37] TrevorParscal: I can handle the

compensation code if you want [19:54:55] nimish_g: Could be templateEditor's getWrapper()'s fault [19:55:10] getAnchor() even [19:55:42] RoanKattouw: tandem commit time [19:55:46] Or wait no [19:55:49] TrevorParscal: Absolutely :D [19:56:09] TrevorParscal: Except in this case I'm gonna wait for yours before I even start coding mine, because I need to test the interaction [19:56:22] nimish_g: Maybe .wrap() triggers some event? [19:58:49] svn up [19:59:29] Yeah saw it [20:00:51] hm, nope just putting a dom element with wikitext in it is enough for it to wrap the template, which is an awesome feature except when you don't want it =) [20:03:15] haha [20:04:54] nimish_g: Try changing the 250 in the .delayedBind() call around jquery.wikiEditor.js:1080 to a higher value like 2500 and see if that causes a delay in it being wrapped [20:05:02] Or even 25000, whatever you need :) [20:05:45] adam_miller: HEADS UP I'm gonna commit a change to context.fn.htmlToText() , the part inside the $('

' + .... + '

') call [20:06:01] adam_miller: If that's inconvenient for you, object now [20:06:16] no do it, i'm still trying to sort out each of the cases i'm handling [20:06:35] hi everyone [20:06:37] OK [20:07:45] I think I found a bug on the deployment prototype: in the insertlink dialog when I type a valid, existing link I see the old -linkicon [20:08:40] You want to have a different icon there? We can do that, give us one :) [20:08:53] nimish and I think it's possible that our hyperactive dom manipulation is causing his issues [20:08:54] whatabout the link icon we use in the toolbar? [20:09:04]

catrope * r61682 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): UsabilityInitiative: Improve performance of
-> newline and

-> newline conversion by regexing easy cases and only using jQuery for the trickier ones [20:09:10] we're going to do more selective updates, like we do with the TOC [20:09:14] OK cool [20:09:32] We can probably put some nice interface for that in the highlight plugin [20:09:54] RoanKattouw: other than responding to my commit, what are you working on / any suggestions for what I should tackle? [20:10:09] Well the selective updates thing maybe [20:10:27] Well, now I guess nimish is poking at that - but yeah [20:10:30] Adam is still poking at the Webkit

thing, he may need help [20:10:32] dang I need to eat something [20:10:36] also I'm still getting that error Index or size is negative or greater than the allowed amount" code: "1 [20:10:36] startNode = startNode.splitText( s.offset ); [20:10:40] adam_miller: how's it going? [20:10:44] What's the recommended way to purge the thumbnails? Just rm -Rf * inside the images/thumb directory? [20:10:58] You should probably explain to Adam what you changed just now with

->
(and presumably the same for

) [20:11:12] nimish_g: Are you up to date? [20:11:17] Or up to the minute rather :) [20:11:21] YEAH it seems to have changed chrome and safari's handling of iframe text [20:11:48] nimish_g: Please svn up and try to reproduce with break on error enabled. Then when it breaks on that error poke me [20:11:56] or should I just kill the thumb directory itself? [20:12:31] nimish_g: Oh wait Firebug doesn't have break on error *hate* maybe do something like if ( s.offset < 0 || s.offset >= startNode.nodeValue.length ) { debugger; } [20:12:46] Ryan_Lane: Don't kill the dir or the structure [20:12:54] Or wait [20:12:58] Lemme look at the structure [20:13:01] ok [20:13:33] this is to make foreign repo actually serve remote files. if the thumbs exist, it serves them [20:13:34] oh wow. RoanKattouw, I just svn up'd...there's about a zillion things going crazy on templates now...that error's still there but...hold on let me get my bearings on what going on... [20:13:41] Yeah so kill everything inside thumb/ but keep thumb/ itself alive [20:13:49] ok [20:14:19] RoanKattouw: any sandboxes or prototypes I should avoid doing this on? [20:14:27] Not that I know of [20:14:27] gonna IT crowd for a bit [20:14:31] ok [20:14:38] It should gracefully handle missing thumbs [20:15:16] nimish_g: Oh wait I know what's wrong [20:15:39] nimish_g: Basically if you want to do anything but

Text

you're now totally screwed [20:15:55] Removing thumbs. May see a little extra slowness on the prototypes for a few minutes. May also see some php warnings due to missing thumbs for a little bit. [20:15:57] Because putting

s inside

s is illegal [20:16:10] nimish_g: I should fix that in the highlight function, will do that later [20:16:11] *TrevorParscal_ is working through IT crowd lunch fyi [20:16:19] Yay [20:16:29] *RoanKattouw praises TrevorParscal's work ethic [20:16:33] Or TrevorParscal_'s, either [20:16:52] *RoanKattouw is working despite complaints from family members that it's Friday night [20:21:15] nkomura: are u around? I just sent u some screenshots. maybe u wanna check them and tell me if you need something else, or different [20:22:40] hi hannes-_- [20:22:48] just got back to my desk from a mtng [20:23:00] ok [20:23:46] *RoanKattouw wonders where Parul is [20:23:50] Jury duty again? [20:24:37] I think she doesn t work on friday [20:24:44] right [20:25:24] Oh right yeah [20:25:29] thanks for the screenshots hannes-_- [20:25:39] I remember that from July, but I can't recall she wasn't in the office Friday before last [20:26:16] nkomura: you r welcome [20:26:36] I ll go offline now - see you guys, have a nice weekend [20:26:44] TrevorParscal_: Looks like my part of the tandem is gonna be one line [20:27:09] awesome [20:27:13] mine was short as well [20:30:36] LOL [20:30:41] After NaNpx there is now nullpx [20:30:52] wow [20:31:17] Oh and IE still won't style diffs [20:31:39] yeah - well, we're not deploying that part, so... no worries [20:33:52] RoanKattouw: eta to commit? [20:34:19] IE is being annoying [20:34:25] My commit works in Firefox [20:34:34] right on [20:37:41] adam_miller: how's it going? [20:39:02] TrevorParscal: my head is killing me :) that's how it's going [20:39:10] you sick? [20:40:17] nooo this problem is just making it hurt [20:40:35] i know what you mean [20:40:51] the weird differences btw safari/chrome and knowing that the code you've got there works(?) in all other browsers [20:41:28] chrome seems to be using all p tags all the time now, but it does shit like

for line breaks [20:41:42] safari looks like it's still using divs in places [20:42:11] TrevorParscal: Did you test whether Safari would be happier with divs instead of

s? [20:42:41] Safari doesn't do crazy nesting with the new

tags [20:42:51] but it still uses divs for new lines [20:42:55] Right [20:43:07] So those still need to be handled as equivalent to

s, presumably [20:43:36] yes [20:44:03] OK WTF IE I hate you [20:44:27] I have a

 containing "Foo
\n\n\nBar" and .text() returns "Foo\n\n\nBar" just fine
[20:44:49] 	But when it's changed to "Foo
\n\n\n\nBar" .text() suddenly returns "FooBar"
[20:45:02] 	"Foo Bar" sorry
[20:50:18] 	TrevorParscal: Meanwhile, do you have time to poke at nullpx?
[20:51:08] 	yes
[20:51:12] 	looking now
[20:53:06] 	ok. Done with all thumbnail stuff. let me know if prototype gets any faster.
[20:53:54] 	Oh God
[20:54:09] 	Apparently ANY DOM manipulation is enough to trigger IE's whitespace collapsing
[20:54:24] 	interesting
[20:54:33] 	Even inside a damn [20:55:05] 	what particular area of the code are you looking at / working on here
[20:55:06] 	?
[20:55:48] 	context.fn.htmlToText(), $pre.find('p').each() function
[20:55:54] 	I think I can cut a corner here, hold on
[21:05:01] 	RoanKattouw: well for now it looks like putting the noinclude tag on it keeps it from being parsed
[21:06:11] 	That's probably true
[21:06:29] 	noinclude -> not wikitext -> skip when parsing
[21:14:38] 	Ugh cutting the corner doesn't completely fix it
[21:15:02] 	IE collapses whitespace in .text(), and it seems the .text() cache in jQuery gets invalidated when you manipulate stuff
[21:18:06] *RoanKattouw 	glares at IE
[21:18:19] 	It has no right to collapse my newlines INSIDE A FRIGGIN' [21:25:26] 	going to grab a coffee and a little fresh air
[21:49:03] 	TrevorParscal: Is there a reason empty 
s must absolutely be converted to 
s?
[21:49:23] 	Oh wait people can still insert 
s
[21:51:54] 	yeah
[21:52:00] 	shift+enter
[21:52:24] 	the 
 -> 
 makes it so we don't have the whole  renders as nothing but still involves 1 space equiv. for deletion / traversal by the cursor
[21:52:50] 	aparently, this is the most common approach for all these reasons
[21:58:50] 	Ah yes
[21:59:17] 	I'm having trouble with IE seizing every opportunity to collapse whitespace in $pre.text()
[21:59:25] 	In places where that's NOT legal
[21:59:40] 	Like: "Blah
\n\nWhee"
[21:59:44] 	Inside a [22:00:06] 	As soon as you manipulate the last , the value of .text() changes to "Blah Whee"
[22:00:24] 	The newlines are still there in the HTML and in the textnodes though, they just get collapsed in .text()
[22:01:23] 	So I've been converting stuff like 
 -> \n and 
 -> \n before passing it into the 
 and it looks like that's just not working
[22:01:46] 	But doing stuff like .find('br').each(function(){ $(this).replaceWith( "\n" ); }); is really inefficient
[22:02:01] 	"that's just not working" means IE messes it up
[22:03:07] 	Oh lol I found a fix
[22:03:17] 	$('' + $pre.html() + '').text()
[22:03:29] 	That's just ridiculous
[22:05:28] 	oh yeah - remember jquery needs the HTML to come in through the selector to avoid collapsing
[22:05:44] 	we learned that a couple weeks ago...
[22:05:53] 	did you document that?
[22:06:12] 	I could if you like.. but it's on your userpage - I don't think I can edit that..
[22:06:20] 	...
[22:10:46] 	You can edit, you did in fact edit it some time ago
[22:10:50] 	And yes, it's there
[22:10:58] 	But the thing is that IE messes up .text()
[22:11:02] 	So I need to like re-init it
[22:11:25] 	Note that this $pre.html() line is AFTER we've already done $('' + html.replace(....) + '') then some DOM manip
[22:11:53] 	that's sad that we have to do this much post processing just to get consistent results from all browsers
[22:12:04] 	this extra processing is only happening on IE right?
[22:12:19] 	AWESOME
[22:12:21] 	That did it
[22:12:34] 	Will put that in browser sniffing yes
[22:12:42] 	Dude this browser compat thing takes sooo much time
[22:14:40] 	maybe add this code to that, and deploy -> http://pastebin.com/f40c8b257
[22:15:44] *TrevorParscal 	awaits commit
[22:15:46] 	hehe
[22:16:00] 	I committed it
[22:16:06] 		catrope * r61692 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): UsabilityInitiative: Fix IE issues with whitespace collapsing with the most ridiculous code ever
[22:16:28] 	yes, it's true, this stuff takes the most time, but don't feel too bad, this sort of experience make you extremely valuable
[22:16:45] 	I know
[22:16:55] 	But hunting for these  things for 3 hours is very annoying
[22:17:01] 	And sleep-depriving
[22:17:09] 	for about 2 years or so.. then new browsers come out and the old ones fade away
[22:17:09] 	Well and it makes me money :)
[22:17:50] 	Unless they rewrite engines though or introduce completely new browsers most of these quirks are gonna remain or be similar in nature to existing ones
[22:22:13] 	Steven Walling just tweeted that Google Docs and Sites no longer support IE6
[22:22:53] 	power to us! http://tcrn.ch/bnPSGr
[22:22:53] 	Heh I totally understand why
[22:23:22] 	I see they've also dropped compat for FF < 3
[22:23:41] 	On one hand that's defensible because 3 and 3.5 are by far the most common Firefoxes these days
[22:23:54] 	On the other hand we haven't managed to write code that blows up on FF 2; yet
[22:25:14] 	adam_miller: Any luck with the  conversion? I committed something again, I hope merge conflicts aren't making your life miserable now
[22:25:50] 	remote desktop locked up on raskin again; in case it happens again, it is possible to ssh into the system, kill the agent, and it'll restart itself. the process to look for in "ps -ef" is "ARDAgent.app". Kill the pid, and it'll relaunch.
[22:26:22] 	Can't you just do killall ARDAgent.app ?
[22:26:30] 	Or does Mac not have that command?
[22:26:34] 	let's see :)
[22:26:48] 	RoanKattouw: line 138 of higlight.js...any reason scan calls itself right after it's been run?
[22:26:49] 	nope
[22:26:56] 	it has killall, but that doesn't work
[22:27:20] 	"killall ARDAgent" on the other hand, does work
[22:27:30] 	nimish_g: It doesn't call itself, it throws the scan event
[22:27:47] 	Not sure that's being used
[22:27:57] 	But that calls evt.scan in all modules as opposed to fn.scan
[22:28:15] 	ok. I'm just trying to de-haunt my iframe =)
[22:29:06] 	I know, but your problems are deeper
[22:29:22] 	I did something to the highlight code that's OK for anchoring but breaks wrapping badlyu
[22:29:56] 	So I know what's going wrong and I will fix it, but right now I'm gonna focus on code that's gonna be deployed
[22:31:22] 	what's our status with the newline handling?
[22:32:12] 	RoanKattouw: i still get dirty diffs on IE8, and while IE7 has clean diffs, it's showing extra lines in the editor -
[22:33:56] 	Lemme look at that
[22:34:01] 	I had a clean diff in IE8 just now
[22:34:26] 	My diff is clean
[22:34:31] 	And I see no extra lines in IE7
[22:37:06] 	TrevorParscal: Which article are you getting dirty diffs on?
[22:37:25] 	Oh wait a second
[22:37:34] 	EditWarning just triggered for me while the diff was clean
[22:38:30] *RoanKattouw 	wonders what's going on
[22:39:11] 	http://pastebin.com/m94018c8
[22:41:57] 	TrevorParscal: Maybe we should cache getContents() calls until we get an event indicating something changes? Something like getContents() and purgeContents(), cf. getOffsets()/purgeOffsets()
[22:42:26] 	TrevorParscal: The article you copypasted diffs clean for me in IE8
[22:45:01] 	hmm
[22:45:49] 	Oh wait maybe I know why EditWarning triggers
[22:45:52] 	\n -> \r conversion
[22:46:09] 	always
[22:46:17] 	ok
[22:46:18] 	um..
[22:46:22] 	Yeah that's it
[22:46:29] 	Lemme do \r -> \n back in htmlToText
[22:46:41] 	when I said 7 and 8, I lied.. the other way around
[22:46:49] 	same behavior, just switch the versions
[22:47:25] 	aka - i still get dirty diffs on IE7 but the editor looks right, while IE8 has clean diffs, it's showing extra lines in the editor
[22:47:54] 	do we know what the difference is between them in the regard?
[22:48:06] 	if we had the editor of one and the diffs of the other... :)
[22:48:31] 	hehe
[22:48:38] 	I have clean diffs on IE8 but EW still fires
[22:49:04] 	Which is ridiculous because getContents() == $textarea.val() is now actually true
[22:49:07] 	Lemme look at IE7
[22:49:51] 	Yeah, dirty diffs on IE7 *hate*
[22:57:55] 	RoanKattouw: I feel like i'm running in circles here. maybe i need to let you or trevor handle this one, or save it for looking at with fresh eyes tomorrow
[22:58:07] 	I think a combination of the two is best :)
[22:58:25] 	adam_miller: understood - no worries, we can work on this together
[22:58:30] 	I will take a look
[22:58:52] 	i think my head is just not quite clear enough to handle this today :)
[22:59:42] 	I think we know what issues remain, and we need to start talking about expectations for release
[22:59:51] 	Let's capture what's left
[23:00:05] 	1. WebKit's use of DIV elements
[23:00:23] 	2. IE's strange whitespace stripping
[23:00:49] 	3. TOC being nesting friendly on IE (i detect this is still unresolved)
[23:00:57] 	What do you mean by 3?
[23:01:33] 	Change 2 to IE7 imagines newlines before headers
[23:01:40] 	k
[23:01:59] 	3, the TOC seems to misbehave in IE, is it working for you?
[23:02:18] 	Misbehave how?
[23:02:18] 	Ryan_Lane: thanks for optimizing prototypes
[23:02:24] 	feels slightly faster
[23:02:27] 	I'm getting invalid argument errors without even editing the document
[23:02:29] 	still testing
[23:02:30] 	nkomura: you're welcome.
[23:02:42] 	sandbox is really fast
[23:02:45] 	hopefully it tides us over some until we can move to tesla
[23:02:47] 	prototypes slightly
[23:02:50] 	yeah
[23:03:01] 	TrevorParscal: nullpx
[23:03:05] 	got to run to a meeting
[23:03:43] 	no, the invalid argument is wikiEditor.js line 625 "range.moveToElementText( sc );"
[23:03:44] 	Ryan_Lane:  loading sf article in sandbox 6 is a lot faster
[23:03:55] 	cool :)
[23:04:05] 	I investigated this for a few hours yesterday and still don't understand why it's failing
[23:04:20] 	IE's debugger has break on error
[23:04:25] 	Use it to find out what sc.nodeName is
[23:04:53] 	argh, stupid vnc locked up again. apple can seriously annoy me sometimes...
[23:05:02] 	http://img684.imageshack.us/img684/2174/picture2ea.png
[23:12:50] 	hmm
[23:13:06] 	now it's working - in debug mode...
[23:14:18] 	does shift+refresh have if ( rand() != 0 ) { cache.clear(); } at the begining of it or something?
[23:14:31] 	(that was a joke - sort of)
[23:15:16] 	Ugh IE7 is not triggering breakpoints for me
[23:18:30] 	on line 645 of wikiEditor.js, sc is a DispHTMLDivElement - as it should be, no?
[23:18:47] 	and yet, moveToElementText is throwing invalid argument
[23:19:32] 	the inner text of sc is ""
[23:19:45] 	so, moveToElementText fails?
[23:20:53] 	it's setting the selection to the heading div, that's what sc is - which is correct behavior afaik
[23:21:10] 	RoanKattouw: isn't it your bedtime a while ago?
[23:21:14] 	did you fall asleep on your keyboard
[23:21:22] 	and now I'm talking to myself .... :)
[23:21:46] 	hehe no worries
[23:21:58] 	just looking out for your health
[23:22:05] 	mental, physical, etc...
[23:22:17] 	Yeah I know, my sleeping schedule has been crazy
[23:22:29] 	I worked till 3:30 AM one night this week
[23:23:13] 	Yeaht the moveToElementText thing seems sane, no idea why that's throwing an error
[23:34:52] 	Ugh
[23:34:57] 	I tracked down the dirty diffs in IE7
[23:35:10] 	Apparently IE7 doesn't support str[0], you have to use str.charAt(0)
[23:35:52] 	When this project is over you and I are gonna write a damn book about IE :)
[23:37:08] 	YAY CLEAN DIFF
[23:37:33] 	i think that's a good idea
[23:38:03] 	intersting - on the string index thing
[23:38:29] 	i actually never use str[0] cause I got burned long ago on that and always though it was unsupported by all browsers
[23:38:54] 	Heh
[23:38:58] 	I tried it in IE8 and it worked
[23:39:05] 	So I was like how bad can it be
[23:39:13] 	CIA-64>	catrope * r61695 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): UsabilityInitiative: IE7 doesn't allow str[0], use str.charAt( 0 ). Also, IE replaces all our \n with \r, convert them back so EditWarning's comparison works
[23:43:46] 	you are amazing RoanKattouw
[23:44:07] 	I'm looking at another one now
[23:44:16] 	IE eats trailing newlines, probably leading ones too
[23:44:26] 	I think I know why
[23:54:01] 	OH YEAH
[23:54:02] 	I got EditWarning to shut up in IE
[23:54:02] 	It was stripping leading and trailing whitespace from the article but it's not anymore now
[23:55:53] 		catrope * r61699 /trunk/extensions/UsabilityInitiative/ (4 files in 3 dirs): UsabilityInitiative: Save trailing and leading whitespace in htmlToText() and restore it later. IE is *really* aggressive about stripping this
[23:58:52] 		catrope * r61700 /trunk/phase3/skins/common/ (jquery.js jquery.min.js): Patch jQuery to test for 'nullpx' as well as 'NaNpx'