| 00:00 | <annevk> | (which is what's used for cross-references) |
| 00:00 | <jennb> | Hixie: yup, reloading changed to fail |
| 00:00 | <Hixie> | jennb: all my browsers show "pass" |
| 00:00 | <Hixie> | jennb: are you testing with your patch? |
| 00:00 | <Hixie> | jennb: (your patch would make it say "fail") |
| 00:02 | <annevk> | zewt, fixed |
| 00:02 | <annevk> | zewt, I hope you are Glenn btw |
| 00:02 | <zewt> | yep |
| 00:03 | <annevk> | anyway, should've been asleep long ago once again; maybe I can figure out some stuff on the plan tomorrow |
| 00:04 | <annevk> | such as how to structure the initial sections and how assimilate the borrowed terminology |
| 00:04 | <annevk> | how to* |
| 00:04 | <jennb> | Hixie: On released Chrome, "fail". On Chrome dev trunk, "pass". That's what I expect. |
| 00:04 | <annevk> | and plan should read plane |
| 00:04 | <jennb> | Hixie: The bug wants 142.html to select Windows-1252 like it used to. |
| 00:05 | <Hixie> | jennb: matching IE8 seems like a better goal than matching an old Chrome |
| 00:06 | <Hixie> | jennb: especially when Firefox and Opera agree with IE8 |
| 00:06 | <jennb> | Hixie: released FF gives me "fail" on 142.html test |
| 00:07 | <Hixie> | jennb: yeah but that's a separate bug |
| 00:07 | <Hixie> | jennb: they don't treat 8859-9 as -1254 |
| 00:07 | <Hixie> | jennb: the point is they get 1254/8859-9 rather than 1252/8859-1 |
| 00:08 | <jennb> | Hixie: oh, i see. My IE also gives me "pass". |
| 00:08 | <jennb> | Hixie: i'll add a note to the bug that IE8 behaviour. |
| 00:08 | <jennb> | s/that/about |
| 00:08 | <zewt> | http://www.hixie.ch/tests/adhoc/html/parsing/encoding/142.html in FF3.6 is "fail", FWIW |
| 00:09 | <Hixie> | zewt: see above, it's a pass for the purposes of this discussion |
| 00:09 | <Hixie> | the failure is the failure you see on 003.html |
| 00:09 | <Hixie> | not the failure we're testing |
| 00:10 | <zewt> | i mean re: '<Hixie> jennb: all my browsers show "pass"' |
| 00:10 | <jennb> | zewt: that was before I reloaded his test. |
| 00:11 | <Hixie> | zewt: ff3.6 shows "pass" if you ignore the fact that it actually says "fail" and just look at the actual results :-P |
| 00:11 | <ap> | Hixie: ff3.6 says "Encoding used by browser is: Windows-1252" |
| 00:11 | <zewt> | ignoring the result, "Encoding used by browser is: Windows-1252", eg. it picks up "cotent" |
| 00:11 | <Hixie> | it does? |
| 00:11 | <Hixie> | huh |
| 00:11 | <Hixie> | well, ff4 uses 1254 |
| 00:12 | <Hixie> | i wonder if they have the same regression on that page then |
| 00:12 | <ap> | Hixie: could also be complicated by content-based encoding sniffer in Firefox |
| 00:13 | <Hixie> | that test should be safe from that |
| 00:13 | <zewt> | yeah, i also see ISO-8859-9 used in FF4b11 |
| 00:13 | <jennb> | if FF has improved their charset detection, we should too. ;-) |
| 00:13 | <ap> | Hixie: they do have the same regression on actual page, yes |
| 00:13 | <Hixie> | interesting |
| 00:13 | <Hixie> | does the actual page work in IE8? |
| 00:13 | <Hixie> | (i have IE8 up here if you can pass me the URL) |
| 00:14 | <ap> | Hixie: https://bugs.webkit.org/show_bug.cgi?id=54582 (you need to log in, not just open the url) |
| 00:14 | <ap> | Hixie: ugh, not sure if I can share the credentials :( |
| 00:16 | <Hixie> | well i can promise that i won't abuse them, since i don't understand a word of this site :-) |
| 00:18 | <Hixie> | ok i got to log in |
| 00:18 | <Hixie> | looks like it works fine in IE8 |
| 00:18 | <Hixie> | dunno why though |
| 00:20 | <Hixie> | the page i get doesn't have a misspelt charset decl |
| 00:21 | <Hixie> | wfm in firefox too! |
| 00:21 | <Hixie> | (trunk) |
| 00:21 | <Hixie> | the decl is: |
| 00:21 | <Hixie> | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> |
| 00:21 | <Hixie> | did they just fix this or am i going crazy? |
| 00:22 | <ap> | Hixie: I'm still seeing "contet" with a typo |
| 00:22 | <ap> | Hixie: even when spoofing UA string in Safari |
| 00:22 | <Hixie> | oh wait |
| 00:22 | <Hixie> | i didn't follow the rest of the intstructions |
| 00:22 | <Hixie> | don't mind me |
| 00:23 | <Hixie> | IE8 is broken too |
| 00:23 | <ap> | Hixie: oh. I guess we shouldn't care then |
| 00:23 | <Hixie> | I vote that we don't fix this. Every browsers is going to have this page broken in the same way in the coming months anyway. |
| 00:23 | <Hixie> | they'll fix it. |
| 00:23 | <Hixie> | interop ftw? |
| 00:24 | <zewt> | heh the key to breaking broken pages: get every browser to expose the bug simultaneously |
| 00:26 | <jennb> | I'll update the bug. |
| 00:28 | <jennb> | Hixie: thanks for checking all the browsers. |
| 00:28 | <Hixie> | np |
| 00:29 | <Hixie> | thanks for bringing it to my attention :-) |
| 00:29 | <Hixie> | it's nice to see all this work we're doing is actually bringing browsers together, even if we're having to break a few eggs in the process |
| 00:29 | <AryehGregor> | :) |
| 00:30 | <zewt> | breaking rotton eggs--at least do it outside |
| 00:30 | <zewt> | also rotten |
| 00:32 | <AryehGregor> | maxlength=30 on an address field. |
| 00:32 | <AryehGregor> | That is just lame. |
| 00:33 | <Hixie> | live somewhere shorter dude |
| 00:33 | <Hixie> | wait, you're in NY |
| 00:33 | <zewt> | heh |
| 00:33 | <Hixie> | aren't your addresses like optimally compressed already |
| 00:33 | <Hixie> | 23rd NE 5th Ave #123 |
| 00:33 | <Hixie> | or some such nonsense |
| 00:34 | <zewt> | worse is "verify your email address" fields with onpaste="return false" |
| 00:34 | <AryehGregor> | Street names are short, avenue names can be long. |
| 00:34 | <AryehGregor> | Apartment number adds to the length. |
| 00:34 | <zewt> | i get annoyed enough at those that I open the DOM and remove the attribute before typing my address twice for no reason |
| 00:34 | <AryehGregor> | I often remove annoying maxlength attributes from the DOM, on the theory that anyone stupid enough to add such a useless check is also stupid enough to not do a server-side check. |
| 00:34 | <Hixie> | zewt: i do that too (though i just always c/p :-) ) |
| 00:34 | <AryehGregor> | Usually I'm right. |
| 00:35 | <Hixie> | hear hear |
| 00:35 | <zewt> | that's the point--it prevents copy and paste on your email address |
| 00:35 | <Hixie> | i mean i remove the attribute and type it once and copy it, not type it twice :-P |
| 00:37 | <zewt> | one time I pasted my phone number into a phone box, and the scripts on the page took the "123-123-1234" i pasted, took "123-123-12" (presumably it tried to remove hyphens in key events), and then refused to let me focus the field again--every time i clicked the field it went "this field's already done!" and focused the next field |
| 00:37 | <zewt> | sometimes pages feel like they were written by the three stooges |
| 00:38 | <AryehGregor> | On a somewhat related note, does anyone else find Chrome's autofill feature incredibly haphazard and confusing? |
| 00:38 | <AryehGregor> | For me, it stores like ten different versions of the same info, with varying levels of completeness, which it often puts in random places when I select one of them. |
| 00:38 | <Hixie> | yes but no worse than any other browsers' |
| 00:38 | <AryehGregor> | I don't think I've used any other browsers'. |
| 00:38 | <Hixie> | i've never had them work for me |
| 00:39 | <zewt> | firefox is always remembering my credit card information. heh |
| 00:39 | <zewt> | "uh ... thanks?" |
| 00:39 | <AryehGregor> | But surely you could make it *slightly* saner. Like attempting to merge the ten autofill entries that are all "Aryeh Gregor". |
| 00:40 | <zewt> | this page makes me lose all hope: http://www.gmacmortgage.com/ |
| 00:41 | <zewt> | ("spot the problem in under five seconds") |
| 00:42 | <AryehGregor> | "Flash" |
| 00:42 | <zewt> | well, that's the underlying problem, but not the important one |
| 00:42 | <gsnedders> | AryehGregor: "Saviour of the universe"? |
| 00:43 | <zewt> | it's a login page that isn't https ... and you can be sure no regular users notice |
| 00:43 | <hober> | gsnedders AryehGregor: Terminator X it! |
| 00:43 | <AryehGregor> | Not using HTTPS is a noteworthy problem in your books? |
| 00:43 | <zewt> | for a login page? |
| 00:44 | <AryehGregor> | What percentage of login pages actually use HTTPS? |
| 00:44 | <AryehGregor> | Like 0.2%? |
| 00:44 | <AryehGregor> | The large majority of sites don't support HTTPS for anything at all. |
| 00:44 | <zewt> | for pages where you pay your mortgage? |
| 00:44 | <zewt> | i've never once seen an online store or anything else that deals with payment/financial information that isn't https |
| 00:45 | <zewt> | now, the login mechanism underneith is flash, and presumably *that* part is still encrypted ... but as it's http, you could MITM it trivially |
| 00:47 | <AryehGregor> | If the site's main page doesn't use HTTPS, you can MITM it anyway, unless you expect the user to notice that the login page is missing the lock icon. |
| 00:47 | <AryehGregor> | (example: http://www.amazon.com) |
| 00:48 | <zewt> | well, normally you do do that--if your main page isn't http, you redirect to https to authenticate, so the https indicators are on |
| 00:48 | <zewt> | but that's just the problem--https depends on users noticing that, and they don't, ever |
| 00:48 | <AryehGregor> | Which is why everyone needs to use STS instead. |
| 00:48 | <Hixie> | there have been studies on this |
| 00:49 | <Hixie> | users do check for the lock |
| 00:49 | <Hixie> | iirc about 25% of people check for the lock in the content area |
| 00:49 | <Hixie> | (and ignore hte browser chrome) |
| 00:49 | <Hixie> | some proportion check for the "https" and ignore the broken-lock warnings |
| 00:49 | <Hixie> | etc |
| 00:49 | <zewt> | Hixie: if that was the case, I'd expect this page to have been fixed long ago--the fact that they don't use http suggests that they don't receive many complaints about it |
| 00:50 | <Hixie> | i don't have any data on this specific case |
| 00:50 | <zewt> | maybe they get lots of complaints and just ignore them all; don't know |
| 00:52 | <AryehGregor> | Look, a useful and detailed bug report from Microsoft: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12091 |
| 00:52 | <AryehGregor> | I guess they've done those before, to be fair. |
| 00:52 | <zewt> | of course, this particular case is broken and insecure, which implies massive incompetence--so I suppose the "receives and ignores complaints" possibility isn't a small one |
| 04:03 | <wirepair> | starting to think CORS was a bad idea. |
| 04:04 | <wirepair> | i've been finding more problems with old code that expectes xhr.open('GET', user_input_url, true); to be 'safe' |
| 04:04 | <wirepair> | :/ |
| 07:42 | <estellevw> | Does anyone know if there is any browser support for image() fallbacks. The 2009 spec reads body {background-image: image(wavy.svg, wavy.png 150dpi, wavy.gif or blue);} |
| 07:44 | <estellevw> | http://www.w3.org/TR/css3-images/#image-notation |
| 08:56 | <zcorpan> | wirepair: should we all do the ie way with a different constructor? |
| 08:57 | <zcorpan> | XDomainRequest or what it's called |
| 09:19 | <mikeke> | Hello all, I have a quick question about the history API |
| 09:21 | <mikeke> | is there something like the same domain policy on it? |
| 11:54 | <annevk> | on the train in Sweden |
| 11:54 | <annevk> | it has the wireless |
| 11:54 | <annevk> | MikeSmith, you around? |
| 11:54 | <annevk> | MikeSmith, was wondering about Web Notifications |
| 11:55 | <jgraham> | Sweden? |
| 11:55 | <jgraham> | Also, lucky you :) They're not all that nice |
| 11:56 | <annevk> | Stockholm for a few days |
| 11:56 | <jgraham> | Unless by "the wireless" you just mean radio ;) |
| 11:56 | <annevk> | will come visit you early March :) |
| 11:56 | <jgraham> | Yes, it is written on out whiteboard |
| 11:56 | <jgraham> | *our |
| 11:56 | <annevk> | haha |
| 11:57 | <annevk> | hg push works |
| 11:57 | <annevk> | and I saw they have 4G here too |
| 11:57 | <annevk> | up to 80mbit |
| 11:58 | <annevk> | at home I've 120mbit, but that's wired |
| 12:00 | <jgraham> | Only in Stockholm though |
| 12:00 | <jgraham> | afaik |
| 12:03 | <jgraham> | Oh, Malmö, Göteborg + Karlskrona |
| 12:03 | <jgraham> | And more polling out this year |
| 12:03 | <jgraham> | *rolling |
| 12:03 | <annevk> | neat neat |
| 12:03 | <annevk> | guess Linkoping has too much students for it to be interesting as a starting point |
| 12:05 | <jgraham> | 550 SEK/month is not cheap |
| 12:05 | <jgraham> | And it looks like the dongle things have the same crappy build quality (and probably the same crappy drivers) as the 3G ones |
| 12:06 | <annevk> | seems we have arrived |
| 13:39 | <beowulf> | anyone know which browsers implement w3c widgets? |
| 13:50 | <zcorpan> | i know opera does |
| 13:51 | hsivonen | isn't aware of any non-Opera browser supporting them |
| 13:51 | <hsivonen> | I hear Apache has a non-browser widget runtime |
| 13:52 | <hsivonen> | and darobin had at least a prototype-level Gecko-based runtime |
| 13:58 | zcorpan | kills the 5 on http://forums.whatwg.org/ |
| 14:00 | <beowulf> | cool, thanks |
| 14:12 | <jgraham> | So if I have <table><form><input> and I remove/reinsert the <input> from the DOM, what form (if any) should it end up associated with? |
| 14:20 | <zcorpan> | jgraham: i think the spec has an algorithm for removing/inserting form controls |
| 14:20 | <zcorpan> | jgraham: which iirc kills the parser's form pointer association and just checks form="" and ancestors |
| 14:21 | <jgraham> | zcorpan: That's what I think too |
| 14:21 | <jgraham> | But I am being held to account for not thinking that two years ago |
| 14:22 | <jgraham> | So I wonder if the spec changed or I am not reading it right now |
| 14:22 | <jgraham> | Also, that's not what Gecko/WebKit do |
| 14:39 | <MikeSmith> | wonder if anybody has taken a look at http://www.w3.org/TR/2010/NOTE-test-methodology-20100128/ |
| 14:42 | <hsivonen> | documents whose title starts with "A Method for" make me think "patent! run away, run away" |
| 14:42 | <hsivonen> | well, at least it's not "Apparatus and Method" |
| 14:42 | <MikeSmith> | heh |
| 14:51 | <jgraham> | MikeSmith: I have scanned it before |
| 15:50 | <MikeSmith> | anybody know how much hardware support OpenSL ES has? |
| 15:50 | <MikeSmith> | http://www.khronos.org/opensles/ |
| 15:50 | <MikeSmith> | "OpenSL ES™ is a royalty-free, cross-platform, hardware-accelerated audio API tuned for embedded systems" |
| 15:52 | <MikeSmith> | jgraham: any opinion on the http://www.w3.org/TR/2010/NOTE-test-methodology-20100128/ idea… it seems to mostly just amount to putting IDs on all testable assertions in a spec |
| 15:53 | <jgraham> | MikeSmith: I think my opinion is roughly "I'm glad I'm not trying to convince Hixie to do that" |
| 15:53 | <MikeSmith> | heh |
| 15:53 | <MikeSmith> | indeed |
| 15:56 | <Philip`> | HTML5 doesn't have a 1:1 correspondence between assertions and elements |
| 15:57 | <Philip`> | or between assertions and continuous sequences of text |
| 15:58 | <Philip`> | e.g. it often says "If X, you must Y. Otherwise, you must Z." where the testable assertions are identifiable as "If X, you must Y" and "If X, [...] Otherwise you must Z" |
| 15:59 | <Philip`> | (You don't want the assertion to just be identified as "Otherwise you must Z" because that loses a critical part of the context) |
| 16:00 | <Philip`> | With the canvas tests I have assertion patterns like |
| 16:00 | <Philip`> | "When the UA is passed an empty string<^> <...> then it *must* return null." |
| 16:00 | <Philip`> | "When the UA is passed <...> a string specifying a context that it does not support<^>, then it *must* return null." |
| 16:00 | <Philip`> | for that kind of thing |
| 16:00 | <MikeSmith> | OK |
| 16:01 | <MikeSmith> | so you're saying your annotations-injection mechanism handles those cases correctly? |
| 16:01 | <MikeSmith> | the one you're using for the annotated canvas spec, I mean |
| 16:01 | <Philip`> | where <...> means any number of characters (within the current paragraph), and <^> means that's where the annotation should be rendered in the spec, and *must* means that's the relevant normative keyword |
| 16:02 | <Philip`> | Yeah, the <...> thing means it's possible for the assertion to include the relevant context without including irrelevant phrases in the middle of the sentence (which might be part of a different assertion) |
| 16:03 | <Philip`> | HTML sadly is tree-structured so you can't really do that in the markup |
| 16:04 | <Philip`> | (at least not without rewriting the text) |
| 16:05 | <Philip`> | (and I don't think rewriting the text of HTML5 would be a necessarily good idea) |
| 16:05 | <jcranmer> | starting over from scratch is always a good thing |
| 16:06 | <jcranmer> | just ask the developers of Duke Nukem Forever |
| 16:06 | <jgraham> | Curiously this is quite close to the first use case I heard for graph-like markup which was annotating the bible |
| 16:07 | <jgraham> | Which I assume, without having any particular knowledge, has similar problems |
| 16:07 | <Philip`> | I imagine people would object if you started over from scratch on the Bible |
| 16:08 | <jgraham> | Well it would be nice to replace the glaring factual errors</flamebait> |
| 16:08 | <jcranmer> | Philip`: it's called the Koran ;-) |
| 16:09 | jgraham | wasn't under the impression that the people who wrote the Koran started out with the Bible and decided to rewrite it from scratch |
| 16:10 | <jcranmer> | well, arguably, everyone who starts their own religion and eschews older texts and writes their own is arguable rewriting it from scratch |
| 17:40 | <MikeSmith> | jgraham: see my reply on testing requirement thread |
| 17:40 | <MikeSmith> | I just created http://www.w3.org/wiki/TestInfra/goals |
| 17:41 | <MikeSmith> | or rather, copied content we had elsewhere over to there |
| 17:47 | <wilhelm> | Cool. |
| 17:47 | <wilhelm> | Re: “allow more than one way to test functionality: … anything else?”, I'd like to know what other browser vendors are doing for tests that require some sort of human interaction. Requiring humans to validate test results doesn't scale. |
| 17:49 | <wilhelm> | There are Watir and WebDriver implementations for all major browsers now, with varying degrees of vendor support. |
| 17:49 | <gsnedders> | wilhelm: Gecko and WebKit pretty much don't do any, just rely upon bugs from users of nightlies, AFAIK |
| 17:51 | <wilhelm> | Opera has a test suite for user interaction with forms with a few hundred tests we could probably contribute. That uses the Watir API and emulates real clicks and keyboard events. The same approach might be useful for other features too. |
| 17:53 | <wilhelm> | gsnedders: Then this might be a good time to decide on something everyone can use in the future. (c: |
| 17:55 | <gsnedders> | wilhelm: WebKit also has https://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree#DumpRenderTreeJavaScriptEnvironment |
| 17:56 | <wilhelm> | Yes, I've seen that one. Looks useful. |
| 17:57 | <gsnedders> | wilhelm: Gecko does something similar at a JS level for testing interaction stuff |
| 19:28 | <Ms2ger> | Gecko has non-automated litmus tests too |
| 19:28 | <Ms2ger> | https://developer.mozilla.org/en/Litmus_tests |
| 19:44 | <MikeSmith> | Ms2ger: odd choice of a name for a class of tests |
| 19:44 | <MikeSmith> | is the name meant to be ironic? |
| 19:45 | <Ms2ger> | Dunno, why? |
| 19:46 | <MikeSmith> | http://en.wikipedia.org/wiki/Litmus_test_(politics) |
| 19:46 | <MikeSmith> | that term has negative connotations |
| 19:46 | <MikeSmith> | seems like it's normally a pejorative term |
| 19:47 | <othermaciej> | in the context of politics it has acquired such a connotation |
| 19:47 | <othermaciej> | but the original term from science is neutral |
| 19:47 | Ms2ger | assumes chemistry is a more likely source |
| 19:47 | <othermaciej> | and it seems totally reasonable to have a binary pass-fail test for software |
| 19:48 | <othermaciej> | well, acid vs. base isn't really a good vs. bad judgment |
| 19:55 | <mikekelly> | anyone about? |
| 19:55 | <Ms2ger> | Nooooooooooooooooooooo |
| 19:56 | <mikekelly> | :-) |
| 19:56 | <mikekelly> | I've got an edge-case HTTP behaviour I was wondering if it had been considered on the browser side.. |
| 19:57 | <mikekelly> | If a 200 response to /foo has a Content-Location header of /foo.html - is it feasible for browsers to adjust their address bar appropriately? |
| 19:59 | <mikekelly> | same thing for a 201 as well |
| 20:11 | <AryehGregor> | That sounds like it's exploitable to prevent users from copying URLs from the URL bar. |
| 20:12 | <mikekelly> | AryehGregor: does the history api suffer from that problem? |
| 20:12 | <AryehGregor> | Dunno about the history API. |
| 20:13 | <mikekelly> | I assume it would, don't know for sure though |
| 20:19 | <gsnedders> | mikekelly: It would be backwards incompatible with deployed content (which relies upon the header being ignored) |
| 20:21 | <mikekelly> | gsnedders: what sort of deployed content are you thinking of, are there any examples? |
| 20:26 | <gsnedders> | mikekelly: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q218/1/80.asp&NoWebContent=1 |
| 20:30 | <mikekelly> | gsnedders: that's a bug, right? |
| 20:31 | <gsnedders> | mikekelly: It's a bug in IIS, yes. But until all the servers using buggy versions of IIS are gone, there's no way browsers are even going to seriously consider supported Content-Location. |
| 20:35 | <mikekelly> | gsnedders: so browsers never make changes that could break buggy applications? |
| 20:38 | <AryehGregor> | They never make changes that will cause their users to complain significantly, unless the practical benefit is really worth it. |
| 20:38 | <gsnedders> | mikekelly: Pretty much. If a site works in version x of a browser and not in version x + 1, users assume the browser is buggy and try another browser. |
| 20:38 | <mikekelly> | AryehGregor: practical to who'm ? |
| 20:39 | <AryehGregor> | To the browser implementers. |
| 20:39 | <AryehGregor> | Or, by extension, their users. |
| 20:39 | <AryehGregor> | Or, by extension, the authors of the pages their users visit. |
| 20:39 | <AryehGregor> | (since their goal is to make users happy) |
| 20:39 | <AryehGregor> | (their users) |
| 20:39 | <mikekelly> | as an author I can tell you that this CL behaviour would be greatly beneficial |
| 20:41 | <AryehGregor> | Doesn't matter, if it will cause too many users to complain to the browser implementers. |
| 20:41 | <AryehGregor> | Even if it didn't, I very much doubt your claim that this will be greatly beneficial to the author of almost any page that browser users visit, weighted by popularity. |
| 20:42 | <mikekelly> | maybe we could meet half way and look at trialling an additional X-Content-Location header with same behaviour? |
| 20:44 | <mikekelly> | gsnedders: if we did the above we have the best of both worlds |
| 20:49 | <mikekelly> | or better "X-Content-Location-Display: true" |
| 21:34 | <Ms2ger> | Reftests almost done... |
| 21:40 | <gsnedders> | Ms2ger: For what? |
| 21:40 | <Ms2ger> | For running them |
| 21:44 | <gsnedders> | Ms2ger: And there you had more all excited about more tests. :( |
| 21:45 | <Ms2ger> | Go review AryehGregor's ): |
| 21:45 | <Ms2ger> | Or :), even |
| 21:57 | Ms2ger | will upload tomorrow |
| 22:25 | <zewt> | heh, is mozilla's tracker *intended* to be impossible to search, with robots.txt preventing it from being indexed... |