| 00:10 | <JakeA> | Hixie: there's a demo linked from http://www.html5rocks.com/en/tutorials/forms/requestautocomplete/ |
| 00:11 | <JakeA> | It's in the wild too, a few SF companies |
| 00:11 | <Hixie> | yeah, that's the one that uses minified JS |
| 00:11 | <Hixie> | i can get that one to work |
| 00:11 | <Hixie> | but i can't get anything simpler to work |
| 00:11 | <Hixie> | even using that page's markup |
| 00:12 | <annevk> | Hixie: are you using it from a UI event handler? |
| 00:12 | <Hixie> | yeah |
| 00:14 | <annevk> | I don't understand the form that pops up from https://googledrive.com/host/0B28BnxIvH5DueUxvWVNsQXd5dU0/ |
| 00:15 | <Hixie> | what's not to understand? |
| 00:23 | <Hixie> | wow, i managed to miss a single row of the 0x80-0x9F numeric char ref mapping table in my code |
| 00:23 | <Hixie> | yay for tests. |
| 00:50 | <annevk-cloud> | Hixie: API is https-only |
| 00:50 | <annevk-cloud> | Hixie: reportedly |
| 04:36 | <Hixie> | annevk-cloud: i tried https |
| 07:41 | <hsivonen_> | Hixie: I'm here now. |
| 08:59 | <gsnedders> | In talk on PNaCl at EuroLLVM… Let's see how this goes. :) |
| 09:05 | <gsnedders> | I guess endianness issues aren't really an issue on the web platform now, because that ship has already sailed even in JS. :( |
| 10:09 | <zcorpan> | gsnedders: we talked about dropping the NCName etc checks in dom core, but since it was already interoperably implemented and well tested it didn't seem worth the cost of changing it |
| 10:42 | <jgraham> | zcorpan: Now I think it mostly is your tests that are causing randomness, and I'm not all that sure how to fix them :| |
| 10:43 | <zcorpan> | jgraham: ok, i can have a look now |
| 10:45 | <zcorpan> | http://hoppipolla.co.uk/410/unstable.txt is what i should be looking at? |
| 10:45 | <jgraham> | zcorpan: I fixed a few of those. |
| 10:45 | <jgraham> | The following, at least, remain: |
| 10:45 | <jgraham> | /html/infrastructure/urls/resolving-urls/query-encoding |
| 10:46 | <jgraham> | /html/semantics/embedded-content/media-elements/interfaces/TextTrack/addCue.html |
| 10:46 | <jgraham> | /old-tests/submission/Opera/preload/auto/ |
| 10:46 | <jgraham> | /webvtt/webvtt-file-format-parsing/webvtt-file-parsing/001.html |
| 10:47 | <jgraham> | /workers/semantics/reporting-errors/003.html (I thought I fixed this one; I wonder if I didn't land the change) |
| 10:49 | <jgraham> | zcorpan: In some cases it seems like the instability only occurs when you run some other tests before the unstable one. I added a tool to wptrunner to work out the minimal set of prior tests needed to get instability. I don't know if that will be useful to you, but if you want to use it let me know and I can give you instructions |
| 10:51 | <zcorpan> | i'll take a stab without it first |
| 10:51 | <jgraham> | Yeah, it's a bit of a last-resort option |
| 10:52 | <jgraham> | (also I need to make a new release that includes it ;) |
| 10:56 | <zcorpan> | EventSource constructor and window.open() first passed and then failed (because they used utf-8). that seems totally wacked |
| 10:57 | <zcorpan> | similar for XMLHttpRequest#open() |
| 10:57 | <jgraham> | (speaking of eventsource /eventsource/format-field-retry.htm should also be on the list) |
| 10:58 | <jgraham> | "totally wacked" as in "Gecko bugs"? |
| 11:01 | <zcorpan> | yeah i think so. but i can investigate some more |
| 11:01 | <zcorpan> | CSS <style> #<id> { background-image:<url> } also |
| 11:03 | <zcorpan> | actually all "CSS <style>" passed on the second run |
| 11:08 | <zcorpan> | jgraham: some of the css tests have TIMEOUTs in http://hoppipolla.co.uk/410/unstable.txt which might not be bugs since css sucks at defining when/if things are fetched. not sure what to do about those, maybe yank them? |
| 11:12 | <jgraham> | zcorpan: In the query-encoding tests? Well if it's testing underdefined behaviour I guess that's a problem |
| 11:15 | <zcorpan> | yeah. http://dev.w3.org/csswg/css-ui/#cursor0 is the spec for 'cursor' |
| 11:22 | <zcorpan> | but the others shouldn't be timing out since the styles are used on the page |
| 11:36 | <zcorpan> | jgraham: i seem to get stable results for query-encoding in chrome |
| 12:23 | <jgraham> | zcorpan: OK, I guess it's Firefox issues. Maybe I will try disabling the unstable tests and filing a bug |
| 12:24 | <zcorpan> | jgraham: yeah that's what i'd recommend for query-encoding. i could comment out the 'cursor' test but i guess that doesn't help you much and anyway it would be good if that was also stable :-) |
| 12:36 | <zcorpan> | jgraham: when running tests, do you run several query-encoding files at the same time? |
| 12:36 | <Ms2ger> | Hmm |
| 12:38 | <jgraham> | zcorpan: Yeah |
| 12:38 | <jgraham> | Well define "same time" |
| 12:38 | <jgraham> | One after another |
| 12:39 | <zcorpan> | like do you have two windows open and start running http://web-platform.test:8000/html/infrastructure/urls/resolving-urls/query-encoding/windows-1252.html before http://web-platform.test:8000/html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html has finished |
| 12:41 | <jgraham> | zcorpan: Not in the production configuration, but that could happen when running with multiple processes |
| 12:41 | <zcorpan> | i think that can cause timeouts. i could get 13 timeouts in one tab in chrome when opening the same test in 6 tabs. and while writing the tests i had to make some tests run "in sequence" in order to not get mass timeouts |
| 12:41 | <jgraham> | zcorpan: Do you know why? |
| 12:41 | <zcorpan> | no :-( |
| 12:42 | <zcorpan> | but it's probably stressing the server with the stach.py thing |
| 12:43 | <jgraham> | That *could* be a bug in the server. In theory it shouldn't matter for the stash if things are run in parallel (that's why you need a UUID as a token) |
| 12:45 | <zcorpan> | it's doing time.sleep(0.01) in a loop until it finds the stash it's looking for or until it reaches a limit |
| 12:45 | <zcorpan> | i understand that it may be a terrible thing to do :-) |
| 12:47 | <jgraham> | That sounds like a pretty terrible thing to do :) |
| 12:48 | <jgraham> | But I kind of see why you might do that |
| 12:48 | <jgraham> | I'll have a look |
| 12:56 | <zcorpan> | jgraham: http://web-platform.test:8000/html/semantics/embedded-content/media-elements/interfaces/TextTrack/addCue.html is not in http://hoppipolla.co.uk/410/unstable.txt and i fail to reproduce randomness in gecko here |
| 12:57 | <zcorpan> | the last test always times out though |
| 12:59 | <jgraham> | zcorpan: I think it might have changed in recently nightlies, but I'm not sure |
| 13:00 | <jgraham> | But I think I failed to reproduce that randomness on my machine too |
| 13:00 | <jgraham> | So it might depend on another test |
| 13:57 | <jgraham> | zcorpan: I wonder if it would make sense to move the polling of the stash to the client rather than the server. I wonder if what you have could cause a problem with connection limits or something |
| 13:58 | <zcorpan> | jgraham: maybe yeah |
| 14:00 | <zcorpan> | jgraham: could it use a websocket maybe? a single websocket for "getting" the stash for all tests? would be cheap to poll there |
| 14:04 | <jgraham> | zcorpan: I guess that's the more advanced option, although it isn't really easy to create websockets that can access the server state |
| 14:04 | <jgraham> | zcorpan: I can try moving the polling to the client and see if it helps |
| 14:07 | <zcorpan> | jgraham: ok. i think you could set some delay for the first poll so that it doesn't always waste one connection that's too early |
| 14:38 | <jgraham> | Aryeh isn't on irc :( (not surprising, but he did just submit a review) |
| 14:39 | <jgraham> | (if he was I would tell him that due to the Magic Of Technology, Ms2ger automatically gets assigned the review) |
| 14:39 | <jgraham> | (But he isn't so I can't) |
| 14:39 | <Ms2ger> | Dammit |
| 14:55 | <gsnedders> | jgraham: Did you see my html5lib review? |
| 14:55 | gsnedders | prods |
| 14:56 | <jgraham> | gsnedders: Yes, but I didn't look at it yet |
| 14:56 | <jgraham> | Maybe this evening |
| 14:56 | <gsnedders> | k |
| 14:56 | <gsnedders> | I want to merge a couple of the other PRs we've got |
| 14:57 | <gsnedders> | But everything fails with Travis CI atm. Because pep8 update introduced new failures. |
| 14:58 | <jgraham> | OK, if it's just trivial things then the review is rather likely |
| 14:58 | <gsnedders> | Yeah yeah, it's really obviously safe stylistic changes |
| 15:23 | <jgraham> | Hmm, so I think I made this test stable in Firefox |
| 15:23 | <jgraham> | But hang in Chrome |
| 15:23 | <jgraham> | That's a good tradeoff, right? |
| 15:32 | <dglazkov> | good morning, Whatwg! |
| 16:08 | <Ms2ger> | gsnedders, because integrating rust into Firefox is an unsolved problem right now, and C++ isn't |
| 16:09 | <jgraham> | context? |
| 16:10 | <Ms2ger> | https://twitter.com/gsnedders/status/453510682911461377 |
| 16:13 | <jgraham> | Oh. Could in theory make a C API wrapper or something. But the build system stuff would be interesting |
| 16:18 | <SimonSapin> | jgraham: has an interesting definition of "interesting" :) |
| 16:20 | <jgraham> | "Interesting" as in "may you live in interesting times" |
| 16:24 | SamB | wonders about a quasi-reference implementation of encodings ... |
| 16:25 | <SimonSapin> | SamB: character encodings? |
| 16:26 | <SamB> | hmm, okay, I added a stray "s": http://encoding.spec.whatwg.org/ |
| 16:28 | <Ms2ger> | jgraham++ |
| 16:29 | <Ms2ger> | gsnedders, also, very little (if any) experience with rust in the security team would mean slower/more likely buggy code writing and reviewing, and calling the library from C++ would still involve crossing through a C API, with all the fun things that implies |
| 16:32 | <jgraham> | zcorpan: Well I pushed a review request, but you might not like it (but that's OK; it's what code review is for :) |
| 17:29 | <gsnedders> | Ms2ger: Integrating into the build system or more generally? |
| 17:29 | <gsnedders> | Ms2ger: Because without stdlib it should be fine, right? |
| 17:29 | <gsnedders> | Ms2ger: And I have more trust in a small C wrapper API than something large written in old-sk00l C++. :) |
| 17:30 | <Ms2ger> | Build system is one of the first things I thought of, yes |
| 17:30 | <Ms2ger> | Especially since we're already spread very thin there |
| 17:31 | <Ms2ger> | (There's basically nobody who's actually paid to work on the build system) |
| 17:36 | <gsnedders> | Well, of course. Why would that matter? It's not profitable! |
| 18:11 | jgraham | discovers that the HTMLWG meeting is bad for his blood pressure even when it is thousands of miles away |
| 18:15 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-archive/2014Apr/0011.html |
| 18:31 | <annevk> | jgraham: why? |
| 18:31 | <annevk> | jgraham: something happening? |
| 18:43 | <Hixie> | jgraham: how is it even affecting you |
| 18:52 | <jgraham> | They are talking about testing |
| 18:52 | <jgraham> | And people are saying things that sound a lot like "we could just delete the tests that fail" |
| 18:53 | <jgraham> | And it's really 386ing me |
| 18:53 | <Hixie> | wow, really |
| 18:54 | Hixie | looks at the calendar |
| 18:54 | <jgraham> | (or even "we could edit the spec so that the behaviour become undefined, and *then* delete the tests") |
| 18:54 | <Hixie> | 2014 and still talking about getting interop by ignoring lack of interop! |
| 18:54 | <Hixie> | gotta love the w3c! |
| 18:54 | <jgraham> | Well I'm hoping that this is just people who didn't get the memo and that darobin will keep them in line |
| 18:55 | <darobin> | no tests are getting deleted |
| 18:55 | <hober> | Fear will keep the local systems in line. Fear of darobin! |
| 18:55 | <darobin> | there are so many better options in the weaseling toolbox |
| 18:56 | <Hixie> | like not weaseling? |
| 18:56 | <Hixie> | oh right, i forgot, w3c. |
| 18:56 | <darobin> | I thought "weasel" was the reason for the initial "w" in anything standards related? |
| 18:57 | <Hixie> | um, no |
| 18:57 | <Hixie> | weaseling is shameful |
| 18:59 | <wilhelm> | jgraham: Who are those people? |
| 19:00 | wilhelm | finds his pitchfork. |
| 19:00 | <Domenic___> | hober++ |
| 19:01 | <MikeSmith> | so should I stop deleting tests now? |
| 19:01 | <Domenic___> | also yeah the recent d3events "let's not specify this" threads on www-dom were O__o |
| 19:01 | <Ms2ger> | Well, it's d3e |
| 19:01 | <Ms2ger> | I don't think they ever got the memo |
| 19:02 | <SamB> | are they like "memo? what is memo?" |
| 19:05 | <Ms2ger> | I didn't see no memo! |
| 19:06 | <Ms2ger> | foolip, did you have a corpus? |
| 19:07 | <Ms2ger> | I'm wondering how much <script type=text/javascript;version=*> happens in the wild |
| 19:25 | <zewt> | weasel hat wg |
| 19:26 | <Ms2ger> | That conjures a nice picture of a weasel in a hat |
| 19:40 | <Domenic___> | the ol' question mark logo's been around for a while, maybe it's time to let a weasel in a hat take over the job |
| 19:43 | <SamB> | Domenic___: doesn't sound like a good favicon ... |
| 19:44 | <SamB> | I mean, unless you get a good drawer and a good pixeler in on it |
| 19:46 | <hober> | Domenic___: http://lists.w3.org/Archives/Public/www-dom/1998JulSep/0342.html |
| 19:46 | <hober> | annevk: ^^ |
| 19:46 | <Domenic___> | O_____O |
| 19:46 | <hober> | annevk: maybe you should use a weasel |
| 19:48 | <Ms2ger> | Oh, good old times |
| 19:48 | <Ms2ger> | Re: document.write to self during load not allowed by PR-DOM |
| 19:48 | <SamB> | PR-DOM ? |
| 20:02 | <annevk> | wut |
| 20:05 | <annevk> | hober: it's somewhat nicer than our cludged tree construct |
| 20:05 | <annevk> | hober: make it green |
| 20:05 | <annevk> | jgraham: now I am sad too |
| 20:19 | <annevk> | Domenic___: whoa, you tweet meed me read the other emails in that thread |
| 20:19 | <annevk> | Domenic___: http://lists.w3.org/Archives/Public/www-dom/1998JulSep/0349.html o_O |
| 20:20 | <Domenic___> | hehe yeah |
| 20:20 | <annevk> | also, I wonder if that's the same Mike Champion that's now Microsoft's AC rep |
| 20:20 | <annevk> | I guess it might be |
| 20:20 | <annevk> | been sixteen years |
| 20:23 | <darobin> | it is |
| 20:24 | <MikeSmith> | it's the same physical person at least |
| 20:32 | <galineau> | yup, same guy |
| 20:33 | <galineau> | wait is MSFT suggesting removing tests? |
| 20:35 | <SamB> | what, MSFT? never! |
| 20:39 | <MikeSmith> | OH: "anally required process" |
| 20:40 | <MikeSmith> | "better get my freight on the freighter" |
| 21:45 | <annevk> | SamB: https://github.com/inexorabletash/text-encoding |
| 21:45 | <annevk> | whoa, galineau |
| 21:54 | <galineau> | annevk, I'm guessing he might have browser tabs as old as you |
| 21:54 | <annevk> | heh |
| 22:13 | <Domenic___> | what's the context on http://w3cmemes.tumblr.com/image/82128157024 ? |
| 22:14 | <Hixie> | heh |
| 22:14 | <Hixie> | i can guess |
| 22:14 | <Hixie> | the w3c won't agree to not copying the whatwg spec |
| 22:15 | <Hixie> | so mike pointed out to them that they might get forced to consider it if i just relicensed the spec to just not allow it |
| 22:15 | <Domenic___> | heh |
| 22:15 | <MikeSmith> | I pointed out more than that |
| 22:16 | <Hixie> | man, the latest memes are a depressing reflection of the w3c |
| 22:16 | <MikeSmith> | but that's the only part what got minuted |
| 22:26 | <Domenic___> | s/depressing/fun |
| 22:26 | <Hixie> | depressing, if what you care about is the web |
| 22:35 | <annevk> | Hixie: if you run a script, are microtasks run at the end? |
| 22:35 | <annevk> | Hixie: e.g. I do new Worker() and in that worker I have a promise that immediately resolves itself, will that return its value before postMessag() stuff starts happening? |
| 22:36 | <Hixie> | those two questions seem unrelated. |
| 22:36 | <annevk> | Hixie: for service workers we want to do a deterministic "has listener" check at the end of initializing the script ideally before microtasks are run |
| 22:36 | <Hixie> | "has listener" should always return true |
| 22:37 | <Hixie> | that is, things should not depend on whether you have a listener or not |
| 22:37 | <annevk> | Hixie: so yeah, that would change here |
| 22:37 | <Hixie> | having a no-op listener and having no listener is the same thing. |
| 22:38 | <Hixie> | (i'm not trying to avoid your questions, i'm not sure i understand precisely what you mean by the original two questions; they seem different and so if they're meant to be the same, i definitely don't understand them.) |
| 22:38 | <annevk> | Hixie: the specification defines an algorithm for running a script given some fetched content |
| 22:39 | <Hixie> | which spec? |
| 22:39 | <annevk> | Hixie: the HTML spec |
| 22:40 | <Hixie> | you mean the <script> processing algorithm? |
| 22:40 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block ? |
| 22:41 | <Hixie> | or http://www.whatwg.org/specs/web-apps/current-work/#create-a-script ? |
| 22:41 | <Hixie> | microtasks run at http://www.whatwg.org/specs/web-apps/current-work/#clean-up-after-running-a-callback if the stack of script settings objects is empty |
| 22:42 | <Hixie> | which is called by http://www.whatwg.org/specs/web-apps/current-work/#jump-to-a-code-entry-point |
| 22:42 | <Hixie> | which is called by http://www.whatwg.org/specs/web-apps/current-work/#create-a-script |
| 22:42 | <Hixie> | which is called by http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block |
| 22:42 | <Hixie> | as well as various other algorithms |
| 22:43 | <annevk> | thanks |
| 22:43 | <Hixie> | they also run after each task |
| 22:43 | <annevk> | so yes |
| 22:43 | <Hixie> | (which is often the same thing) |
| 22:45 | <Hixie> | but seriously, don't do anything based on whether you have a listener ornot |
| 22:45 | <Hixie> | that's a layering violation |
| 22:52 | <TabAtkins> | annevk: Why are you trying to do something different based on the presence of a listener? |
| 22:53 | <zewt> | awooga awooga |
| 23:01 | <TabAtkins> | Ah, now I see the reasoning: https://github.com/slightlyoff/ServiceWorker/issues/225 |
| 23:02 | <TabAtkins> | They want to skip the ServiceWorker entirely if there's no listener registered for a given event, since it's guaranteed to fall back to the network stack. |
| 23:02 | <Hixie> | isn't that an implementation detail? |
| 23:03 | <hober> | it's not if they want to ignore subsequent listener additions |
| 23:03 | <TabAtkins> | Technically, yes. The part that needs some spec language is defining *precisely* when a UA is allowed to assume there's no listener. |
| 23:03 | <TabAtkins> | There's some timing issues. |
| 23:04 | <Hixie> | i would phrase it differently then |
| 23:04 | <Hixie> | i would say that you fire the events at that time, or some such |
| 23:04 | <Hixie> | not that you don't fire the event if it doesn't have a handler |
| 23:04 | <Hixie> | but this all seems like an implementation detail |
| 23:05 | <hober> | Hixie: look at the code example in https://github.com/slightlyoff/ServiceWorker/issues/225 |
| 23:05 | <TabAtkins> | And what hober said - they want to only allow functional listeners to be registered during install/update, not randomly, so that the fact of whether a SW is going to handle a request or not doesn't change in a way that would expose nondeterminism in request dispatch. |
| 23:05 | <Hixie> | i did |
| 23:05 | <TabAtkins> | In other words, they need to know about listener registration during some temporal periods and not others. |
| 23:05 | <Hixie> | i don't really understand what that code snippet is suggesting |
| 23:06 | <TabAtkins> | Imagine that, instead, SWs had to explicitly say "I'm going to handle fetches" (or other kinds of network activity). |
| 23:06 | <TabAtkins> | The list of things to handle could only be updated during an install/update. |
| 23:06 | <Hixie> | that seems like a reasonable api approach |
| 23:06 | <TabAtkins> | And if you didn't explicitly say so, you dont' get sent anything. |
| 23:07 | <hober> | even if you subsequently "change your mind" as in the self.onfetch in that example |
| 23:07 | <Hixie> | better than doing anything based on what listeners are present, certainly |
| 23:07 | <TabAtkins> | They're just trying to reduce boilerplate and reduce the chance of mistakes by making the registration mechanism "add a listener". |
| 23:07 | <TabAtkins> | Becasue saying you're going to handle fetches, and then not defining a fetch listener, is stupid. |
| 23:07 | <Hixie> | well then why not just have the logic be "when a listener is added, do X", like MessagePort does? |
| 23:07 | <TabAtkins> | And so is defining a fetch handler, but not declaring that you'll handle fetches. |
| 23:08 | <TabAtkins> | Yeah, I think that's all that needs to be done. |
| 23:08 | <Hixie> | that seems better than any weird timing things |
| 23:09 | <Hixie> | i mean, this is why message ports have start() |
| 23:09 | <Hixie> | there's setting onmessage, which is "explained" as being the same as addEventListener() followed by start() |
| 23:10 | <Hixie> | seems better than checking for listeners |
| 23:10 | <TabAtkins> | Yeah, the deal is that there's a defined period where they want to listen for registrations, and no more after that. |
| 23:11 | <Hixie> | sure |
| 23:11 | <TabAtkins> | So you have to nail down the timing correctly, so that it can be documented exactly when listeners stop being paid attention to. |
| 23:11 | <Hixie> | so long as they "explain" it properly with an api that doesn't actually rely on this, that's fine |
| 23:11 | <TabAtkins> | ? |
| 23:12 | <Hixie> | like the message port thing above |
| 23:12 | <zewt> | most cases i've seen where people think they want to detect whether an event listener exists, what they should really be doing is basing it on whether preventDefault was called |
| 23:12 | <TabAtkins> | zewt: Unrelated to this case. |
| 23:13 | <TabAtkins> | You're talking about when people are trying to detect "was this event handled by the system, or did JS get a crack at it?". |
| 23:13 | <TabAtkins> | They're talking about whether to even fire events at a SW, based on whether the SW is set up to listen to them. |
| 23:14 | <zewt> | no, I'm in particular talking about the webglcontextlost WebGL event, where as I recall they wanted to say "if there are any listeners for webglcontextlost, then enable context loss. otherwise they don't support it, so do something different" (not precisely, been too long for the details) |
| 23:15 | <zewt> | oh, for automatic context restoration |
| 23:16 | <zewt> | "if there are any listeners for webglcontextlost, then the client knows about automatic context restoration and we'll do it. otherwise it's older code, so don't automatically restore the context" |
| 23:16 | <zewt> | got changed to "if webglcontextlost is cancelled, enable context restoration" |
| 23:17 | <zewt> | (i'm still getting it wrong, but the details aren't important here anyway) |
| 23:25 | <TabAtkins> | Yeah, that makes more sense in that case. |