[13:30:05] <hashar>	east coaaaastt
[13:30:18] *hashar 	looks for east coast gang sign
[13:36:00] <MaxSem>	our cross the pond gang is stronger!
[15:31:31] <petan|w>	hexmode: please check https://www.mediawiki.org/wiki/MediaWiki_1.19/Roadmap/status I inserted some text related to deployment site
[15:31:49] <petan|w>	once you become online :o
[15:32:18] <hexmode>	petan|w: if you're not sure I'm online, it is better to PM me
[15:32:31] <petan|w>	oh, right
[15:32:33] <petan|w>	hi :)
[15:32:42] <petan|w>	I sent you few messages at -operation
[15:32:58] <petan|w>	+s
[15:34:16] <hexmode>	petan|w (and whoever else): dircproxy queues up PM's to send them to me when I'm not online so I def see them.  I can go look at the logs for in-channel stuff, but I usually don't
[15:46:06] <petan|w>	hexmode: you are available now or not
[15:46:20] <petan|w>	I just wanted to update you about the progress
[15:46:26] <hexmode>	petan|w: sorry, I'm here now
[15:46:33] <petan|w>	ok
[15:46:43] <petan|w>	yesterday someone rebooted deployment-web
[15:46:50] <hexmode>	yes
[15:46:51] <hexmode>	me
[15:46:58] <hexmode>	it was hung up
[15:47:03] <hexmode>	and you weren't around
[15:47:07] <petan|w>	that stopped the import and put it db to bad state... so I was unable to restore it
[15:47:14] <hexmode>	ryan said  it was OOM
[15:47:24] <petan|w>	however I started another import with help of apergos
[15:47:33] <petan|w>	it's much faster now
[15:47:41] <petan|w>	should be finished in 3 days (full)
[15:48:08] <hexmode>	:)
[15:48:16] <hexmode>	this is simple, right?
[15:48:25] <petan|w>	yes
[15:48:40] <petan|w>	the previous site is useable too it contains some pages
[15:48:46] <hexmode>	and, were you aware of the OOM or what caused it?
[15:49:06] <petan|w>	no, I will try to check it but the import now is running in a completely different way
[15:49:43] <petan|w>	I think it makes sense it crashed importDump is not designed for so big db
[15:49:51] <hexmode>	? have you documented how the "right" way to run it is anywhere
[15:49:53] <hexmode>	yeah
[15:50:01] <petan|w>	yes I will write it somewhere
[15:50:03] <hexmode>	we should file a bug :)
[15:50:16] <petan|w>	probably but I have no idea where labs bugs belong
[15:50:34] <petan|w>	Ryan wanted to use RT for labs
[15:50:37] <hexmode>	I've always used importDump but  would like to  know a better way
[15:50:40] <hexmode>	b00!
[15:50:44] <hexmode>	no RT
[15:50:46] <petan|w>	I use mwimport
[15:50:48] <hexmode>	or at least
[15:50:56] <hexmode>	not RT as it currently is
[15:51:18] <hexmode>	one tracking system to rule them all....
[15:51:29] <petan|w>	I would rather use bz too
[15:51:42] <hexmode>	since this is  me and you
[15:51:51] <hexmode>	and since this is for public stuff
[15:52:01] <hexmode>	shall I set up a bz category?
[15:52:15] <petan|w>	hm, if there isn't one yet
[15:52:18] <hashar>	hexmode: I sent you a private message about  XCF file format :D
[15:52:19] <petan|w>	yes
[15:53:02] <hexmode>	hashar: thanks, missed that.  And you ROCK very hard
[15:53:59] <hashar>	hexmode: I hate blank thumbnails :D
[15:54:16] <hashar>	hexmode: is XCF thumbnailed by imagemagick?
[15:54:32] <hexmode>	hashar: very very badly
[15:55:20] <hexmode>	if you  have  multiple XCF layers, im will do  it but it sucks b/c layers are  not sized and positioned correctly
[15:55:44] <hexmode>	so, if we could find some im dev to fix that...
[15:55:55] <hashar>	tip:  /join #imagemagick   ?:))
[15:56:01] <hashar>	I don't even have gimp on my comp
[15:56:15] <hexmode>	apt-get install gimp
[15:56:18] <hashar>	yeah
[15:56:31] <hashar>	need to find out a repository of debs for ...
[15:56:34] <hashar>	??? mac os X !!
[15:58:01] <^demon>	hashar: Your options for osx are pretty much homebrew or macports.
[15:58:08] <^demon>	Fink is horribly outdated.
[15:58:43] <hashar>	macports just keep compiling stuff
[15:58:45] <hashar>	I use brew
[15:58:50] <hashar>	which does not have gimp :-\
[15:59:04] <hashar>	oh no
[15:59:09] <hashar>	I am STUPID
[15:59:10] <^demon>	You could download a .dmg for gimp
[15:59:11] <hashar>	really
[15:59:17] <^demon>	And skip the packages :p
[15:59:22] *hashar 	launch his ubuntu virtual machine & apt-get install gimp
[15:59:49] <hashar>	I was like "My debian machine is at home and shut downed, can't launch gimp there"
[16:00:01] <^demon>	http://gimp.lisanet.de/Website/News/News.html has gimp packages for osx.
[16:00:56] <hashar>	the ubuntu vm is fine :D
[16:01:33] <hexmode>	petan|w: "Wikimedia Labs" product added to Bugzilla.  "Setup" is the only component for now.
[16:02:36] <petan|w>	ok
[16:20:36] <petan|w>	hexmode: if you want I could create more wikis with a limited number of pages
[16:20:42] <petan|w>	like en wiki etc
[16:21:37] <hexmode>	petan|w: enwiki sure... I'm thinking I want to do something with commons since it is so different, but I'll talk to some people in -commons today before I go farther
[16:21:56] <petan|w>	right
[16:22:00] <petan|w>	how many pages you want
[16:22:27] <hexmode>	10% ?? I dunno... I think mostly I'm worried about gadgets
[16:22:56] <hexmode>	anyway to get all of Mediawiki: namespace and a couple hundred of the rest?
[16:23:51] <bawolff>	if your importing pages to do a test install, its a good idea to pick some pages, then make sure all needed templates are included
[16:24:23] <hexmode>	bawolff: that makes sense... what about gadgets, though?
[16:24:47] <bawolff>	I vaugely remember someone made a test install for 1.17 or 1.16 that had missing templates everywhere that looked totally broken from all the redlinks
[16:25:56] <bawolff>	gadgets would probably be hard to test fully unless you have the gadget authors on board
[16:27:33] <petan|w>	10
[16:27:37] <petan|w>	10% is too many
[16:28:07] <petan|w>	I will try to get some 2000 content pages, all and some from other spaces (1000 from each)
[16:28:20] <petan|w>	* some from
[16:28:29] <hexmode>	bawolff: and I plan to do get gadget people... I would hate to get this w/o them
[16:28:31] <petan|w>	s/all//
[16:28:47] <petan|w>	it's no problem to get shell access there
[16:28:50] <petan|w>	it's on labs
[16:29:09] <hexmode>	anybody know where gadget people hang out?  Would enwiki's WP:VPT be good?
[16:29:16] <petan|w>	yes
[16:29:22] <petan|w>	you should definitely notifiy people there
[16:29:28] <bawolff>	#wikipedia-userscripts maybe
[16:29:38] <bawolff>	but on wiki is always good
[16:31:56] <petan|w>	it's no problem to let people register there and do tests of their scripts etc
[16:32:26] <petan|w>	we could avoid the issues we had last time, there were many complains on VPT after deployment of 1.18
[16:35:57] <hexmode>	Another IRC channel being added
[16:39:23] <hexmode>	petan|w: exactly what I'm trying to do :)
[16:40:24] <petan|w>	hexmode: which
[16:40:33] <petan|w>	I mean a channel
[16:40:42] <hexmode>	-userscripts
[16:40:55] <petan|w>	ah I thought -deployment :D
[16:40:57] <petan|w>	ok
[16:42:32] <hexmode>	I don't think I want to do that... I have too many already
[16:42:46] <petan|w>	heh
[16:43:18] <petan|w>	if we created that irc log search system I talked about on wikitech it would be way easier
[16:43:26] <petan|w>	because we could just search through all our channels
[16:44:08] <petan|w>	you would type 1.19.*suck to search box and would see all the people complaining about unknown problems :D
[16:44:39] *hexmode 	grants petan|w 10minutes to create such a thing
[16:45:04] <petan|w>	I will work on that but I hoped some other php devs would join me
[16:47:09] <hexmode>	petan|w: I'm no good at starting projects... get something that works badly up so I can help improve it ;_
[16:48:15] <petan|w>	np
[19:53:22] <petan>	hexmode: if you are around and could get some more people who would be interested in set up of the clone it would be cool
[19:53:44] <petan>	I am now working on en wiki but have a slow progress since I am only person who work on that
[19:54:10] <petan>	I don't know if you need to have it working soon or not
[20:04:58] <Ryan_Lane>	hexmode: is this deployment-prep stuff going to be a wiki setup similar to the cluster/
[20:05:08] <Ryan_Lane>	meaning we deploy via the deployment scripts and such?
[20:05:20] <Ryan_Lane>	if so, can we put the deployment tools on bastion?
[20:05:31] <Ryan_Lane>	hmm
[20:05:35] <Ryan_Lane>	that may be hard right now
[20:05:45] <RoanKattouw>	Ideally you'd have a VM that plays bastion
[20:05:49] <Ryan_Lane>	yes
[20:05:53] <Ryan_Lane>	well, bastion could also work
[20:06:08] <Ryan_Lane>	where you need to be in the deployment project to deploy
[20:06:19] <Ryan_Lane>	since it's a group, we can expand on that
[20:06:27] <Ryan_Lane>	just like we have wikidev in production
[20:06:45] <Ryan_Lane>	but no one has root right now on bastion, so it's likely a PITA to configure
[20:07:49] <RoanKattouw>	Why don't we just do this on a separate VM? It seems to be much easier and cleaner (and closer to reality!) that way
[20:07:59] <Ryan_Lane>	that's fine too
[20:08:46] <Ryan_Lane>	won't that require people to forward their agent from bastion to that vm too?
[20:09:08] <Ryan_Lane>	I'd *really* like to separate the deployment stuff from the webserver crap
[20:09:16] <Ryan_Lane>	I hate that we run a web server on our bastion host
[20:16:46] <RoanKattouw>	You mean fenari?
[20:16:53] <RoanKattouw>	We don't /need/ to run a web server there, it's only for noc
[20:17:04] <RoanKattouw>	The deployment infrastructure will function without running Apache on fenari
[20:17:13] <RoanKattouw>	But yes, you'll need key forwarding in that case, that's annoying
[20:17:19] <Ryan_Lane>	yeah
[20:17:28] <Ryan_Lane>	let's start with keeping it separate
[20:17:33] <Ryan_Lane>	back in a little bit. lunch.
[21:19:29] <RoanKattouw>	Ohai Krinkle
[21:19:44] <Krinkle>	Heyo
[21:19:47] <RoanKattouw>	I tested the async-head-JS stuff, and it works in all browsers (!)
[21:19:54] <RoanKattouw>	There was one issue with IE initially but I fixed it
[21:20:04] <Krinkle>	you started from scratch I assume ?
[21:20:05] <RoanKattouw>	https://toolserver.org/~catrope/async/
[21:20:08] <RoanKattouw>	Aye
[21:20:22] <RoanKattouw>	Now changing mw.loader and OutputPage.php to use this
[21:20:35] <RoanKattouw>	Optionally, though, behind something like $wgUseExperimentalAsyncLoading
[21:21:05] <Krinkle>	btw, if you care, var a = +new Date; works too
[21:21:13] <RoanKattouw>	hah, nice
[21:21:26] <Krinkle>	something with prototype toNumber or something like that,
[21:21:51] <Krinkle>	it's not really in the prototype though\
[21:23:31] <Krinkle>	RoanKattouw: document vs. document.documentElement ?
[21:24:11] <Krinkle>	document.documentElement.getElementsByTagName('head')[0] is empty in Chrome, as there is no <head> in <body>
[21:24:46] <Krinkle>	interesting
[21:25:25] <Krinkle>	I know document.head isn't in IE. but I assume it's document.getElementsByTagName('head')[0] for IE (document=<html>, document.body / document.documentElement is=<body>)
[21:25:45] <Krinkle>	RoanKattouw: is "documentElement" needed ?
[21:26:56] <RoanKattouw>	wtf
[21:27:04] <RoanKattouw>	document.documentElement is not <html> everywhere?
[21:27:08] <Krinkle>	no where
[21:27:27] <RoanKattouw>	My IE console disagrees with you, IIRC, let me check
[21:27:34] <Krinkle>	W3C specified ['documentElement'] instead of ['body'] so they could change the name of <body> later on
[21:27:46] <Krinkle>	lol
[21:27:48] <RoanKattouw>	>>document.documentElement.nodeName
[21:27:49] <RoanKattouw>	"HTML"
[21:27:55] <Krinkle>	he ?
[21:27:56] <Krinkle>	\
[21:28:09] <RoanKattouw>	And Firebug disagrees as well :D
[21:28:10] <RoanKattouw>	>>> document.documentElement
[21:28:12] <RoanKattouw>	<html class="client-js" lang="en" dir="ltr">
[21:28:31] <Krinkle>	oh, right. it's ['documentElement'] instead of ['html']. I remember W3C mentioning that.
[21:28:46] <RoanKattouw>	But yeah obviously doc.getElementsByTagName should work too
[21:28:55] <Krinkle>	right
[21:29:01] <RoanKattouw>	It's just that I used doc.docElement.children[0] initially
[21:29:24] <Krinkle>	ok
[21:52:05] <Krinkle>	RoanKattouw: k, I've reproduced it for my own convenience: http://toolserver.org/~krinkle/tmp/rl-async/
[21:52:14] <Krinkle>	could've asked your script, but now I understand it inside out :)
[21:52:57] <RoanKattouw>	You could've just viewed source, right?
[21:53:12] <RoanKattouw>	The only page you couldn't readily view was load.php but that's three lines
[21:53:13] <Krinkle>	yeah, I did, for the helm part
[21:53:14] <Krinkle>	html*
[21:53:36] <Krinkle>	sure, I copied it. but went though line by line.
[21:54:00] <RoanKattouw>	Oh, OK
[21:54:12] <RoanKattouw>	There is one thing I'm kind of struggling with
[21:54:20] <RoanKattouw>	scripts-only requests in the bottom
[21:54:32] <RoanKattouw>	Right now they're <script src="..."> tags at the bottom of the body
[21:54:39] <RoanKattouw>	I'm moving 'bottom' to the <head> as well
[21:54:56] <RoanKattouw>	So I'll need to do something to make those load async
[21:55:09] <RoanKattouw>	I considered using the async attribute, but that's not supported by older browsers
[21:55:21] <RoanKattouw>	So what I'm leaning towards doing now is <script>mw.loader.load( 'url' );</script>
[21:55:32] <Krinkle>	hm.. what do you mean ? You have an async-in-all-browsers method now right >?
[21:56:07] <RoanKattouw>	Yes
[21:56:18] <RoanKattouw>	Basically, what I have is this
[21:56:22] <RoanKattouw>	mw.loader.setBlocking( true );
[21:56:29] <RoanKattouw>	mw.loader.load( ['top', 'queue' ] );
[21:56:31] <Krinkle>	Oh, right. scripts=only aren't injected by JS
[21:56:32] <RoanKattouw>	mw.loader.setBlocking( false );
[21:56:41] <RoanKattouw>	mw.loader.load( [ 'bottom', 'queue' ]);
[21:56:43] <Krinkle>	they should be in order to make them load async
[21:56:49] <RoanKattouw>	exactly, they're <script> tags in the HTML
[21:56:54] <RoanKattouw>	Yes
[21:57:03] <RoanKattouw>	So what I'm gonna do is just make them loader.load calls
[21:57:18] <Krinkle>	yeah, so we need only=scrips support
[21:57:23] <Krinkle>	that works too
[21:58:54] <Krinkle>	RoanKattouw: It's really quite simply once it's figured out
[21:59:06] <Danny_B|backup>	the deployment enwiki seems to be misconfigured
[21:59:47] <Krinkle>	natural script tags and doc-write is sync everywhere, and injected script tags are async everywhere (either always so in old browsers, or configurable and by default true in new browsers)
[21:59:50] <RoanKattouw>	heh yeah
[21:59:54] <Krinkle>	Danny_B|backup: What's up ?
[21:59:57] <RoanKattouw>	Yup
[22:00:24] <Danny_B|backup>	Krinkle: i see go / search buttons
[22:00:41] <Danny_B|backup>	and the search suggest doesn't work
[22:00:56] <Krinkle>	Danny_B|backup: since when ? logged in ?
[22:01:01] <Danny_B|backup>	yes
[22:01:17] <Krinkle>	I don't have go/search on en.wp and search suggest works fine
[22:01:20] <Krinkle>	logged out
[22:01:22] <Krinkle>	lemme try log in
[22:01:26] <Danny_B|backup>	not enwp
[22:01:36] <Krinkle>	same thing
[22:01:41] <Krinkle>	you said enwiki
[22:01:47] <Danny_B|backup>	the deployment.wmflabs.org/en_wikipedia
[22:01:57] <Krinkle>	"the deployment enwiki"
[22:02:00] <Reedy>	lol
[22:02:00] <Krinkle>	ok
[22:02:09] <Krinkle>	#wikimedia-labs maybe :)
[22:02:12] <Reedy>	Danny_B|backup, they're still settting that stuff up
[22:02:14] <Krinkle>	sorry
[22:02:28] *Krinkle 	recovers from heart attack
[22:02:57] <Krinkle>	RoanKattouw: I wonder why headJS is so complicated if it's this simple..
[22:03:12] <Krinkle>	we might even have broader support here than headJS
[22:03:12] <RoanKattouw>	Well
[22:03:24] <RoanKattouw>	They're also using a 300ms delay because otherwise caching doesn't work in some browsers
[22:03:42] <RoanKattouw>	I haven't tested that very much, all of my scripts were marked uncacheable to test the timing properly
[22:03:54] <Krinkle>	Hm..
[22:03:56] <RoanKattouw>	But I didn't set the headers right for IE initially, and IE cached them just fine
[22:04:17] <Krinkle>	so you check cache by seeing if it does the sleep again for the load.php request ?
[22:04:45] <RoanKattouw>	Yes
[22:05:03] <RoanKattouw>	I'll change load.php on my TS test thingy
[22:05:09] <RoanKattouw>	To make everything cacheable for a week
[22:05:31] *Krinkle 	is stealing bits.wikimeida.org headers
[22:05:54] <RoanKattouw>	done
[22:06:18] <RoanKattouw>	wfm in firefox 8
[22:06:44] <RoanKattouw>	The headers I'm using are Cache-Control: public, s-maxage=604800, max-age=604800      Expires: Thu, Jan 12 19:00:08 GMT
[22:07:00] <Krinkle>	ok
[22:07:54] <Krinkle>	HTTP/1.1 304 Not Modified ?
[22:08:05] <RoanKattouw>	?
[22:08:12] <Krinkle>	or is that not needed
[22:08:16] <RoanKattouw>	It should just grab it from client-side cache
[22:08:21] <RoanKattouw>	No, don't use 304, just let it use client-side cache
[22:08:25] <Krinkle>	ok
[22:11:39] <Krinkle>	RoanKattouw: you're in browserstack ? (just checking before I do)
[22:11:52] <RoanKattouw>	Yes
[22:11:55] <Krinkle>	ok, cool
[22:11:56] <RoanKattouw>	Want me to get out of there?
[22:11:58] <Krinkle>	no
[22:12:09] <RoanKattouw>	Well I'm not actively in it
[22:12:22] <RoanKattouw>	I'm coding right now
[22:13:09] <Krinkle>	RoanKattouw: did you check cache in all browsers ?
[22:14:33] <RoanKattouw>	No
[22:14:38] <RoanKattouw>	Would you mind doing that
[22:14:40] <RoanKattouw>	?
[22:14:43] <Krinkle>	ok
[22:14:44] <Krinkle>	http://etherpad.wikimedia.org/RL-mwloader-testcases-tmp
[22:14:47] <Krinkle>	using browserstack
[22:15:01] <RoanKattouw>	dude
[22:15:05] <RoanKattouw>	I've already made that list
[22:15:09] <Krinkle>	:)
[22:15:14] <RoanKattouw>	http://etherpad.wikimedia.org/RL-async-head
[22:15:18] <Krinkle>	right
[22:15:26] <RoanKattouw>	(you couldn't know that of course)
[22:22:42] <Krinkle>	RoanKattouw: would be nice if etherpad had tables, or google docs had etherpad behaviour
[22:22:46] <Krinkle>	wait, it does
[22:28:57] <Krinkle>	RoanKattouw: Im adding another one to my test, 2 from docwrite and 2 from insert. making sure the bottom two load simulatinous
[22:29:00] <Krinkle>	parallel
[22:31:58] <Krinkle>	RoanKattouw: http://toolserver.org/~krinkle/tmp/rl-async/
[22:32:08] <Krinkle>	two docwrites go in parrallel
[22:32:13] <Krinkle>	not sure if they're blocking
[22:32:32] <Krinkle>	oh they are, domready is delayed by it
[22:32:32] <Krinkle>	cool
[22:32:44] <Krinkle>	as well as start of loading of the other two
[22:40:50] <Krinkle>	RoanKattouw: Hm.. how do you confirm the bottom queue is going async ?
[22:41:03] <Krinkle>	if domready is delayed, how to determine the difference ?
[22:42:20] <Krinkle>	Ah right, there should be 2 seconds between appearing of initial text and the filling of the numbers
[22:46:30] <RoanKattouw>	yes
[22:46:44] <RoanKattouw>	Yes, docwrite is blocking in a strange way
[22:46:52] <Krinkle>	Looks like async didn't go in Opera 11.6
[22:47:03] <Krinkle>	in my local one, will try browserstack's version in a sec
[22:47:09] <Krinkle>	did you get the google doc ?
[22:47:19] <Krinkle>	ah you just joined
[22:47:48] <RoanKattouw>	Ywah
[22:48:18] <RoanKattouw>	What's your test page?
[22:49:00] <Krinkle>	http://toolserver.org/~krinkle/tmp/rl-async/
[22:49:04] <Krinkle>	I'm testing yours too
[22:49:14] <Krinkle>	to see if https makes any difference and whatever else is different
[22:49:38] <RoanKattouw>	What went wrong in Opera?
[22:50:13] <Krinkle>	Nothing appeared until bottom scripts were loaded, not sure where to attribute that too
[22:50:16] <Krinkle>	I guess not going in async ?
[22:50:30] <Krinkle>	not just dom ready, but nothing appeared and then everything including numbers
[22:50:37] <RoanKattouw>	Right
[22:50:38] <Krinkle>	hadn't seen that anywhere else
[22:50:46] <RoanKattouw>	That's what I said on the Etherpad too
[22:50:53] <RoanKattouw>	dom ready is delayed by the async scrips
[22:51:07] <RoanKattouw>	Opera 11.6: ok, BUT document ready delayed until after async scripts load
[22:51:09] <Krinkle>	usually it starts with either all with .. and then numbers coming in, or, also common, everything appears except still ??? for bottom queue. both are good.
[22:51:15] <RoanKattouw>	Yes
[22:51:26] <RoanKattouw>	The Opera behavior is not an improvement but it's not a regression either
[22:51:29] <Krinkle>	but the latter case in my previous message includes a delayed dom ready
[22:51:41] <RoanKattouw>	It's effectively the same as bottom-of-the-body script behavior
[22:51:51] <Krinkle>	delayed domready doesn't mean per se that nothing appears until bottom scripts are loaded.
[22:52:07] <RoanKattouw>	Oh, right
[22:52:18] <Krinkle>	looks like opera 11.6 is actually blocking some how
[22:52:20] <RoanKattouw>	I wonder how Opera behaves for bottom-of-body scripts then
[22:52:32] <RoanKattouw>	Hmm wait
[22:52:33] <Krinkle>	like, <body> doesn't go until they're in
[22:52:37] <RoanKattouw>	I haven't actually set s.async
[22:52:49] <Krinkle>	maybe opera's default is async is false
[22:52:52] <RoanKattouw>	Yeah
[22:54:14] <Krinkle>	RoanKattouw: what about 'defer' ?
[22:54:25] <RoanKattouw>	hmm, right
[22:54:30] <Krinkle>	http://www.sitepoint.com/non-blocking-async-defer/
[22:54:58] <Krinkle>	defer delays execution until around domready but downloads already in async
[22:55:07] <Krinkle>	wheraes async executes on delivery
[22:55:11] <Krinkle>	we probably want the latter
[22:55:25] <RoanKattouw>	yeah
[22:56:25] <Krinkle>	according to MDC:
[22:56:26] <Krinkle>	script-inserted scripts execute asynchronously in IE and WebKit, but synchronously in Opera and pre-4.0 Firefox
[22:56:35] <Krinkle>	no version for Opera
[22:57:13] <Krinkle>	anyway, continuing testing for now
[23:04:39] <Krinkle>	RoanKattouw: source-code pasted in Sheet2
[23:10:14] <RoanKattouw>	OK, this seems to work in WM
[23:10:16] <Krinkle>	brion: Do you have IE10 beta ?
[23:10:16] <RoanKattouw>	*MW
[23:10:26] <RoanKattouw>	Krinkle: I'll send you my patch
[23:10:29] <Krinkle>	RoanKattouw: cool
[23:10:33] <RoanKattouw>	Actually, hell, I'll just commit it
[23:10:37] <RoanKattouw>	It's behind a feature flag
[23:11:25] <Krinkle>	:)
[23:13:00] <brion>	Krinkle, yeah i've got win8 dev preview running
[23:13:12] <Krinkle>	brion: cool
[23:13:31] <Krinkle>	brion: Im sharing a google doc with your wm.org addy
[23:16:35] <Krinkle>	brion: could you check that doc and fill in for IE10 beta ? There's 4 columns with tests to run on the url underneath the table, each column has a short description with how to confirm the behavior
[23:16:45] <Krinkle>	4 tests*
[23:19:12] <Krinkle>	RoanKattouw: I can't help notice that so far all browsers I've tested actually don't use any funky keyboard shortcuts anymore for hard refreshes
[23:19:24] <Krinkle>	the only way to do a non-hard refries is to press return in the address bar
[23:19:33] <Krinkle>	any press on refresh will ignore all cache
[23:19:44] <RoanKattouw>	hm
[23:19:59] <Krinkle>	that's extra detectable now with sleeps in our scripts :)
[23:20:05] <RoanKattouw>	There might still be a difference regarding whether they send Cache-Control: max-age=0 in their request headers though
[23:20:07] <RoanKattouw>	yeah :)
[23:23:27] <brion>	Krinkle, not sure how to match up all those #s offhand; and this machine is overloaded with VMs so will tend to be slowish
[23:23:46] <Krinkle>	brion: the scripts have a php sleep() in them.
[23:23:58] <Krinkle>	should still be possible
[23:24:14] <Krinkle>	try the best you can, it's just an indication
[23:26:32] <Krinkle>	RoanKattouw: Wow, safari 4 on windows even does a clean refresh when pressing enter in addy bar. onyl way I could get a cached one there is by opening a new tab and pasting the url. it apparently detected the refresh-action by pressing return in the current uncached addy bar. freaky
[23:27:20] <Krinkle>	somewhat makes sense though, it's not bad for users. almost no non-tech user does anything refresh-like
[23:27:49] <RoanKattouw>	Clicking a self-link works sometime
[23:27:51] <RoanKattouw>	s
[23:28:26] <Krinkle>	yup, that works in Safari 4 too
[23:28:37] <Krinkle>	I'll do that from now on, much easier than reaching up there
[23:28:39] <Krinkle>	thx
[23:29:04] <Krinkle>	oh, there is none on our test page though.
[23:29:13] <Krinkle>	:D
[23:29:22] <Krinkle>	ctrl+l;enter; is fast enough
[23:29:27] <RoanKattouw>	Well no, but standard MW pages have self-links
[23:29:32] <RoanKattouw>	("Read" tab)
[23:29:41] <Krinkle>	yep
[23:30:10] <Krinkle>	RoanKattouw: So far they even copy random query strings (I read a bug about that last week),someone wanted the "Special page" tab on special pages to be without query string.
[23:31:01] <RoanKattouw>	?
[23:31:04] *RoanKattouw 	doesn't follow
[23:31:06] <RoanKattouw>	Oh
[23:31:09] <RoanKattouw>	Yeah, I understand
[23:31:23] <RoanKattouw>	It should be the canonical link, usually
[23:31:28] <RoanKattouw>	For special pages it makes sense
[23:33:34] <Krinkle>	brion: does the text with ??? appear before it is filled in ?
[23:33:45] <brion>	yes
[23:33:51] <Krinkle>	then "Bottom queue async" is OK
[23:34:03] <brion>	\o/
[23:34:05] <Krinkle>	sorry, description is a bit weird
[23:34:07] <brion>	:D
[23:36:50] <Krinkle>	RoanKattouw: brion: I've changed visibility of  the spreadsheet  from "Private" to "public via read-only link"
[23:36:52] <Krinkle>	https://docs.google.com/spreadsheet/ccc?key=0ApsGwg5TzvlwdG11YVBWMU9WYnVYbzI3Rm9lbGd6S2c
[23:37:13] <Krinkle>	just so you know, so don't' put like your password in there (wtf)
[23:37:21] <RoanKattouw>	OK
[23:37:32] <RoanKattouw>	I am sort of worried about the Opera behaviro
[23:38:49] <RoanKattouw>	I've changed http://toolserver.org/~catrope/async/ , what does that do in Opera now
[23:38:51] <RoanKattouw>	?
[23:40:11] <RoanKattouw>	OK, yeah, this is broken in Opera
[23:40:15] <RoanKattouw>	Screw you, Opera
[23:40:42] <RoanKattouw>	I'll look into making Opera happier but I need sleep now
[23:41:19] <brion>	:D
[23:41:33] <Krinkle>	ok
[23:41:38] <Krinkle>	I've opened a thread here: https://www.mediawiki.org/wiki/Talk:Compatibility#Update_A-grade_browser_support
[23:42:11] <RoanKattouw>	!r 108184
[23:42:11] --elephant--	http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108184
[23:42:16] <RoanKattouw>	I've commented noting the Opera bug
[23:42:23] <Reedy>	I want some updated browser stats
[23:42:25] <RoanKattouw>	It's possible that we just need to append to something else
[23:42:28] <Reedy>	IE6 is < 1% in the USA now
[23:43:49] <Krinkle>	btw, I"m convering that talk page to LQT now
[23:44:48] <Krinkle>	doe
[23:44:49] <Krinkle>	done
[23:45:53] <Krinkle>	brion: You don't' happen to have Safari 3 ?
[23:49:16] <Krinkle>	RoanKattouw: Ah, right. We don't insert from <script> but from scripts that are loaded through <script>
[23:49:40] <RoanKattouw>	Yes
[23:49:58] <RoanKattouw>	The code appends to the <body> or the <head>, whichever is available
[23:50:06] <RoanKattouw>	Appending to the <html> works in FF (it's what HeadJS does) but not in EI
[23:50:08] <RoanKattouw>	*IE
[23:50:16] <RoanKattouw>	Maybe it works in Opera, I'll have to play with it
[23:50:46] <RoanKattouw>	I have Opera 11.51 locally
[23:50:55] <brion>	nope, no old safaris
[23:51:07] <Krinkle>	ok
[23:51:25] <Krinkle>	RoanKattouw: okay, so yes here there is initial text before foo2.js is loaded, domready still delayed though
[23:51:37] <Krinkle>	this is to see if current MW is ok ?
[23:52:15] <Krinkle>	so when in the bottom of <body> it's okay. opera doesn't wait for <body> to end, it simply didn't' start <body> when loading from head.
[23:52:27] <Krinkle>	RoanKattouw: that was about your new version on toolserver in opera 11.6
[23:52:38] <RoanKattouw>	Oh
[23:52:40] <RoanKattouw>	Yeah, sorry
[23:52:49] <RoanKattouw>	index2.html has the old behavior
[23:52:56] <RoanKattouw>	I just needed a straight-up bottom-of-the-body test case
[23:53:02] <Krinkle>	RoanKattouw: Can you load two from the bottom ?
[23:53:06] <RoanKattouw>	Sure
[23:53:38] <Krinkle>	and add some random html after it, it probably doesn't show that other html until those two are loaded
[23:54:14] <RoanKattouw>	done
[23:54:41] <RoanKattouw>	Firefox does that too BTW
[23:54:47] <RoanKattouw>	The text isn't shown until the scripts are loaded
[23:55:49] <Krinkle>	RoanKattouw: I made a variation on mine in index-script_async_true.html to see if setting .async=true on a SCRIPT injection from head helps opera.
[23:55:55] <Krinkle>	no luck, still blocks <body>
[23:58:20] <Krinkle>	RoanKattouw: if you wanna go sleep, don't let me hold you up. I did find this steve sounders page: http://stevesouders.com/tests/delayed-script-execution.php
[23:58:33] <Krinkle>	it takes 10 seconds+ to load