| 04:02 | <Domenic> | Anyone with latest Safari mind testing if Array.prototype.includes is present? |
| 04:05 | <Domenic> | Also Uint8Array.prototype.includes |
| 04:10 | <tantek> | Safari 6.1.6 returns undefined for both |
| 04:11 | <Domenic> | Sorry, should have specified I was looking for Safari 8 and 9 |
| 05:27 | <miketaylr> | Domenic: neither in Safari 8.0.5 |
| 05:27 | <Domenic> | I have reports of it being in 8.1 |
| 05:47 | <terinjokes> | Domenic: 8.1 here |
| 05:48 | <terinjokes> | Array.prototype.includes đź‘Ť, Uint8Array.prototype.includes đź‘Ž |
| 08:30 | <annevk_> | JakeA: I guess we could revisit the new Request() aspect of fetch(), if someone has the time, though that still leaves open what new Request() should do |
| 08:31 | <JakeA> | annevk: I'm not suggesting it's wrong, just couldn't work out why it was different |
| 08:32 | <annevk> | JakeA: so request has a pointer to a stream; then you create a new request that then gets to own that stream |
| 08:32 | <annevk> | JakeA: the old request now no longer has a pointer to a stream, sure, the used flag can be set, but body would be null |
| 08:32 | <annevk> | JakeA: and then you get into the thing what null body should mean... |
| 08:34 | <JakeA> | annevk: ahh, I thought new Request(request) would create a new stream that read from the original request stream |
| 08:34 | <JakeA> | your way is more efficient |
| 09:00 | Domenic | has been reading too much C++... this is basically auto_ptr vs. shared_ptr |
| 09:01 | <Domenic> | I am not sure what the use case is for a "copy constructor" for Request anyway? |
| 09:26 | <annevk> | Domenic: mostly to normalize the request |
| 09:26 | <annevk> | Domenic: while making sure we don't forget anything |
| 09:26 | <Domenic> | In what case can a Request be un-normalized? |
| 09:27 | <annevk> | Domenic: the one passed to FetchEvent |
| 09:28 | <annevk> | Domenic: (and anything passed to FetchEvent that's then passed to cache.put()) |
| 09:28 | <Domenic> | annevk: how did the author generate an un-normalized Request to pass to FetchEvent though? |
| 09:28 | <annevk> | Domenic: the UA did |
| 09:29 | <Domenic> | annevk: why would the UA do something seemingly crazy like that? |
| 09:29 | <annevk> | Domenic: it's not crazy, it reflects the settings for the document, but not all of those can be used for the service worker, so you need a reset of sorts before you go to the network |
| 09:29 | <annevk> | Domenic: the document/worker/shared worker* |
| 09:30 | <Domenic> | Hmm. I don't really understand, but I'll take your word for it... |
| 09:31 | <annevk> | Domenic: e.g. the client of a request passed to FetchEvent will be the document/worker |
| 09:32 | <annevk> | Domenic: but the request resulting from fetch() should always have a client that is the global environment |
| 09:32 | <annevk> | Domenic: there's a ton of stuff like that |
| 09:32 | <Domenic> | hmm |
| 09:32 | annevk | refers back to his Twitter rant about not enough people understanding what is going on |
| 09:33 | <jochen__> | hey annevk Domenic :) |
| 09:33 | <jochen__> | so what about the promise rejection events? |
| 09:33 | <annevk> | hahaha |
| 09:33 | <jochen__> | do you think mozilla will implement them? |
| 09:33 | <annevk> | Oh, wait, I thought you said cancelation |
| 09:34 | <annevk> | bz seemed open to implementing them |
| 09:34 | <jochen__> | would be cool to get some feedback on the current spec |
| 09:34 | <annevk> | I didn't really follow that thread admittedly |
| 09:34 | <annevk> | jochen__: pointer? |
| 09:34 | <jochen__> | impl. in blink is done % feedback from other vendors |
| 09:34 | <jochen__> | https://github.com/domenic/unhandled-rejections-browser-spec |
| 09:35 | <jochen__> | + the three pull requests from me :) |
| 09:35 | <Domenic> | jochen__: I need to update for https://github.com/domenic/unhandled-rejections-browser-spec/issues/2#issuecomment-113226244 |
| 09:35 | <Domenic> | it seems like this is a new phase after microtasks |
| 09:35 | <annevk> | https://github.com/domenic/unhandled-rejections-browser-spec/issues/1 seems important |
| 09:36 | <Domenic> | Sigh, I should do that too, it's just so much less exciting |
| 09:36 | <jochen__> | #1 is spec'd and implemented, so just close it? |
| 09:36 | <Domenic> | To be clear, it's about *Worker objects having .onunhandledrejection etc. |
| 09:36 | <Domenic> | No, #1 is not specced or implemented |
| 09:36 | <Domenic> | Worker global scopes have the events. Worker objects do not yet. |
| 09:36 | <jochen__> | ah |
| 09:37 | <jochen__> | not sure that's desirable |
| 09:37 | <annevk> | "Environment settings object seems to be a place to dump stuff?" sounds about right |
| 09:37 | <Domenic> | haha |
| 09:37 | <jochen__> | that would require dispatching the events cross process |
| 09:37 | <Domenic> | jochen__: yeah, it's kind of a "nobody has asked for this, but it's consistent with onerror" thing |
| 09:38 | <annevk> | Does Worker's onerror fire for all exceptions or just during compile? |
| 09:38 | <jochen__> | i'd be surprised |
| 09:39 | <Domenic> | Good question... bz seemed to imply all errors, but worth checking... |
| 09:39 | <annevk> | I do agree that being consistent would be nice |
| 09:39 | <jochen__> | if it fired for all exceptions |
| 09:39 | <annevk> | And it doesn't seem super hard to post a message across the process... |
| 09:39 | <jochen__> | because out of process |
| 09:39 | <jochen__> | what would the message contain? |
| 09:39 | <Domenic> | Nah, all errors https://html.spec.whatwg.org/multipage/workers.html#runtime-script-errors-2 |
| 09:39 | <Domenic> | "For dedicated workers, if the error is still not handled afterwards, the user agent must queue a task to fire a trusted event that uses the ErrorEvent interface..." |
| 09:40 | <Domenic> | ohhhh interesting |
| 09:40 | <Domenic> | "and with the error attribute initialised to null" |
| 09:40 | <annevk> | jochen__: sorry, I meant internally the browser would use a message to transmit the error... |
| 09:40 | <Domenic> | instead of trying to structured clone the error object or something |
| 09:40 | <Domenic> | that is the problem in this case |
| 09:40 | <annevk> | there's no structured cloning of Error objects |
| 09:40 | <Domenic> | to get a coherent PromiseRejectionEvent you'd have to structured clone the { promise, error } object |
| 09:40 | <Domenic> | yeah |
| 09:40 | <Domenic> | so we could fire an event with no information... |
| 09:41 | <jochen__> | right |
| 09:42 | <Domenic> | The best we could do (messy) is switch from promise objects to promise IDs, and then also have a message field (optionally lineno/columno/filename). |
| 09:42 | <Domenic> | Seems not worth it |
| 09:42 | <annevk> | I think we should fix structured cloning of Error btw: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28389 |
| 09:43 | <Domenic> | s/of Error// ;) |
| 09:43 | <annevk> | maha |
| 09:43 | <annevk> | good luck with that |
| 09:43 | <jochen__> | there's no guarantee that the reason is a an error |
| 09:43 | <jochen__> | could be an array buffer |
| 09:43 | <annevk> | But yeah, promises seems harder |
| 09:43 | <Domenic> | ^ right, also that |
| 09:43 | <annevk> | true |
| 09:44 | <jochen__> | so: no events on *Worker objects :) |
| 09:44 | <Domenic> | We should get bz's buy in on that, but it sounds good to me... |
| 09:44 | <jochen__> | also, the event isn't really like the error event |
| 09:44 | <annevk> | I mean in the other case we also fire without any information... |
| 09:44 | <Domenic> | in the other case we have message/lineno/colno/filename |
| 09:44 | <jochen__> | that has a lot of special implications that are just not true for this event, i.e., it's own kind of event listener |
| 09:45 | <jochen__> | so what about this phase after microtask checkpoint thing |
| 09:45 | <annevk> | Domenic: you can just do null defaulting in the dictionary |
| 09:46 | <annevk> | Domenic: since the event cannot be constructed without the dictionary that's fine |
| 09:46 | <Domenic> | annevk: this null thing is quite confusing actually |
| 09:46 | <Domenic> | annevk: Firefox seems to give undefined for things HTML says are null |
| 09:47 | <annevk> | oh |
| 09:47 | <Domenic> | HTML is imprecise |
| 09:47 | <annevk> | You don't have to use null |
| 09:47 | <Domenic> | let me find what i am talking about |
| 09:47 | <annevk> | And you could require both a promise and a reason |
| 09:48 | <annevk> | not sure what "require any reason" would imply though, I guess best to leave that optional |
| 09:48 | <annevk> | (or even better, figure out what that means) |
| 09:51 | <jochen__> | Domenic: did you see my new pull requests btw? |
| 09:51 | <Domenic> | jochen__: yeah, I've been having fun with V8 extras today, will probably merge when I get home from work |
| 09:51 | <Domenic> | annevk: here is an example of null that confuses me. https://html.spec.whatwg.org/multipage/comms.html#messageevent |
| 09:51 | <Domenic> | "The data attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to null." |
| 09:51 | <Domenic> | But (new MessageEvent({})).data === undefined |
| 09:52 | <annevk> | Domenic: that's a bug |
| 09:52 | <Domenic> | Maybe because of how the constructor works? But teh constructor isn't specified outside of IDL as far as I can tell. |
| 09:53 | <annevk> | We have a generic description for event constructors: https://dom.spec.whatwg.org/#constructing-events |
| 09:53 | <annevk> | It needs some cleaning up though to work with internal slots and stuff, but IDL hasn't formalized those :-( |
| 09:53 | <Domenic> | Ah OK, that's nifty |
| 09:53 | <Domenic> | So that definition implies .data === undefined I think since {}.data === undefined |
| 09:53 | <annevk> | But note that if a dictionary member is undefined it's missing so it wouldn't be set by that constructor |
| 09:53 | <Domenic> | So I guess... null only matters for UA created MessageEvents that don't bother to set data? |
| 09:54 | <Domenic> | Hmm |
| 09:54 | <annevk> | So it would be null per the prose rules |
| 09:54 | <Domenic> | "for each dictionary member defined therein find the attribute on event whose identifier matches the key of the dictionary member and then set the attribute to the value of that dictionary member" I dunno |
| 09:54 | <Domenic> | "data" sounds like a dictionary member defined therein |
| 09:54 | <annevk> | But instead of relying on prose it's way better to just default to null in the dictionary for events that can't be created through document.createEvent() |
| 09:55 | <Domenic> | OK well defaulting to null seems like a good plan I'll file that on myself and fix later. |
| 09:55 | <annevk> | Domenic: I think IDL says that if a member is "undefined" it's not defined |
| 09:56 | <Domenic> | I read it as referring to the actual definition, i.e. `dictionary MessageEventInit { ... }` |
| 09:56 | <annevk> | Nope, it refers to the argument passed |
| 09:57 | <annevk> | But it should use "present" and "not present" as terminology... |
| 09:57 | <Domenic> | *shrug* |
| 09:57 | <Domenic> | bbiab, food time |
| 10:07 | <jochen__> | enjoy |
| 10:50 | <JakeA> | wanderview: that bug report on Twitter… Firefox fails a CORS check for fetch('//other-origin/foo') from a page, even if the serviceworker returns a valid non-opaque response |
| 11:09 | <annevk> | I wonder why Google Calendar can confirm via email that someone is attending but cannot actually show that information in the event... Maybe a bug specific for organizations using Google Calendar? |
| 11:41 | <annevk> | Domenic: it seems weird that Streams makes many states unobservable |
| 11:41 | <Domenic> | annevk: streams are supposed to be largely stateless |
| 11:41 | <annevk> | Domenic: e.g. not being able to distinguish an empty stream from a non-read canceled stream is just... uh |
| 11:41 | <Domenic> | annevk: e.g. consider arrays, you don't care how the array became empty |
| 11:41 | <Domenic> | they're a data structure, not a record of what's happened in your system |
| 11:42 | <annevk> | Hmm, guess I have to think about it more |
| 12:06 | <annevk> | Domenic: why is it a good thing that they don't keep track? Most asynchronous data structures seem to keep track in some way... |
| 12:07 | <annevk> | And more specifically I'd think most stream implementations would keep track of such details |
| 12:25 | <Domenic> | annevk: no async data structures I can think of keep track. Certainly not promises. No data structures in general, that I can think of. Why? Hmm... |
| 12:25 | <annevk> | Domenic: https://w3c.github.io/FileAPI/#dfn-Blob does |
| 12:26 | <Domenic> | annevk: no, it definitely doesn't. Example: |
| 12:26 | <annevk> | Domenic: isClosed? |
| 12:26 | <Domenic> | You can't distinguish between a blob with [1,2,3,4,5] created from scratch, versus a blob with [1,2,3,4,5] created from slicing a blob [1,...,1000] |
| 12:27 | <Domenic> | sure, but all closed blobs are the same |
| 12:27 | <Domenic> | nobody cares if the closed blob used to have 1000 bytes in it or 0 |
| 12:27 | <annevk> | but they're distinguishable from empty blobs |
| 12:27 | <Domenic> | i mean, empty but not-yet-closed streams are distinguishable from empty-and-closed streams |
| 12:28 | <Domenic> | it's just that if you know there's no more data to put in the stream, there's not much point in keeping the stream unclosed. |
| 12:28 | <annevk> | I thought wanderview said that was not true |
| 12:28 | <Domenic> | just makes it annoying for anyone to figure out whether the stream is over yet |
| 12:28 | <Domenic> | same as blobs |
| 12:29 | <Domenic> | ehhhh it's borderline, it's a matter of whether .getReader().closed fulfills immediately or not |
| 12:30 | <Domenic> | we could add synchronous querying of the fact, but in general it's better to just write generic code that isn't so concerned with the state, and deals with the generic starts-readable-becomes-closed scenario, with starts-readable-immediately-becomes-closed as a special case. |
| 12:31 | <annevk> | I guess it's okay, it seems somewhat weird that if you cancel a stream it's suddenly treated as the empty string, but folks will deal |
| 12:32 | <Domenic> | remember you can only cancel if you "own" it (i.e. you can get a reader) |
| 12:36 | <annevk> | So actually, is that not a problem for the synthetic case we've been discussing? |
| 12:36 | <Domenic> | hmm how so? |
| 12:37 | <annevk> | You can now empty any response from a server and the browser cannot tell whether the server returned the empty string or someone meddled with the stream |
| 12:37 | <Domenic> | @#&*()*$ |
| 12:38 | <Domenic> | OK. I will think about that tomorrow. That caught me by surprise a lot. Dammit. |
| 12:41 | <annevk> | We should just have an isDirty flag, would work instead of offset too... :-P |
| 12:41 | <Domenic> | I mean, last time my mind was blown, I went from "no state!!" to "OK I guess offset is not the worst thing ever." Maybe tomorrow I'll come around to isDirty :( |
| 12:42 | <Domenic> | I guess a wrapper also would handle all of this |
| 12:42 | <annevk> | Would that impact speed? But sure... |
| 12:42 | <Domenic> | But yhirano_ worries about performance, especially with piping |
| 12:42 | <Domenic> | yeah |
| 12:43 | <annevk> | Ideally what we expose here is the lowest of the lowest-level stuff, minus all the security bugs |
| 12:43 | <Domenic> | in theory it shouldn't but in the still-somewhat-speculative world of off-main-thread piping, it could. So far that world is pretty vague but we've tried to maintain enough flexibility. |
| 12:52 | <Domenic> | You can also do yhirano_'s preferred wrapper https://github.com/yutakahirano/fetch-with-streams/pull/43#issuecomment-110968431 which should not impact perf |
| 12:52 | <Domenic> | i should sleep |
| 14:35 | <annevk> | jochen__: Domenic: https://bugzilla.mozilla.org/show_bug.cgi?id=1179244 |
| 14:37 | <jochen__> | "Your password fails to meet the security requirements" blabla |
| 14:54 | <smaug____> | annevk: so the promise event stuff will be in DOM or HTML spec? |
| 14:54 | <smaug____> | at least the DOM Event part of it? |
| 14:54 | <annevk> | it's described as patches to HTML and ECMAScript |
| 14:56 | <smaug____> | another question, annevk did you figure out where and when the custom element meeting actually will be? |
| 14:57 | <smaug____> | (even if I had stronger opinions on custom elements, the timing is rather bad. July is the holiday month in Finland ) |
| 14:57 | <annevk> | smaug____: not yet, the ball is with slightlyoff it seems |
| 14:57 | <annevk> | smaug____: it's very likely in Mountain View |
| 14:58 | <annevk> | smaug____: but it could move to San Francisco I suppose |
| 14:58 | <annevk> | I'm staying in San Francisco since that's where the service worker meetup will be, I believe |
| 14:58 | <smaug____> | oh, right, that one too |
| 15:00 | <smaug____> | waiting to see the time when SW is stable and implemented everywhere |
| 15:00 | <smaug____> | maybe next year |
| 15:30 | <MikeSmith> | annevk: the custom elements meeting is on July 21st, right? < smaug____ |
| 15:30 | <annevk> | MikeSmith: yes |
| 15:31 | <smaug____> | yes, that one, but still unclear where |
| 15:32 | <MikeSmith> | ah ok |
| 15:33 | <MikeSmith> | I assumed it will be at Google in Mountain View where we had it last |
| 15:33 | <MikeSmith> | *where we had the Shadow DOM meeting |
| 15:33 | <MikeSmith> | but that room was too small |
| 15:33 | <MikeSmith> | and not arranged so well |
| 15:34 | <MikeSmith> | or I dunno, maybe that actually helped the meeting be more productive |
| 15:49 | <annevk> | I hope there's not going to be a ton of people... |
| 15:52 | <JoWie> | no holographic telepresence at google yet? |
| 16:23 | <smaug____> | annevk: MikeSmith: one thing which made the last meeting a bit hard was the proposals coming right before the meeting |
| 16:23 | <smaug____> | getting proposals a week earlier or so would have perhaps made the meeting even more productive |
| 16:24 | <annevk> | smaug____: agreed |
| 16:25 | <annevk> | I've been trying to do my homework https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors but so far that has made me skeptical of doing Custom Elements at all... |
| 16:29 | <smaug____> | annevk: btw, I think cloning for printing isn't perhaps that interesting case, since we wouldn't probably run ctors, but try to clone whatever there is in shadow DOM or so, I think |
| 16:29 | <smaug____> | not sure though |
| 16:30 | <smaug____> | in Gecko we don't run scripts in the clone document |
| 16:30 | <smaug____> | beforeprint may change the original document right before printing and then afterprint restore the state after cloning |
| 16:30 | <smaug____> | as of now |
| 16:31 | <annevk> | smaug____: if in order to create an element you need to run its constructor, cloning would need to do that too |
| 16:32 | <smaug____> | not sure about clone-for-printing |
| 16:32 | <smaug____> | that is rather odd case |
| 16:32 | <annevk> | bz likes to bring it up |
| 16:32 | <annevk> | but same goes for text selection and then copying things |
| 16:32 | <smaug____> | it just needs some state which can be printed |
| 16:33 | <annevk> | sure |
| 16:33 | <smaug____> | selection is perhaps more valid case, and just plain normal cloneNode() |
| 16:34 | <annevk> | cloneNode() invoking some JavaScript seems harmless |
| 16:34 | <annevk> | the parser invoking JavaScript is potentially problematic, since non-</script> points are not vetted |
| 16:35 | <annevk> | and then there's various algorithms in browsers that want to clone elements, such as printing and editing, that might not anticipate the world to change |
| 16:36 | <smaug____> | cloneNode(true): when should the ctors run? |
| 16:42 | <annevk> | smaug____: prolly in tree order |
| 16:43 | <annevk> | philipj: richt: davve: is the plan to support Web Audio without <audio> / <video> indirection? |
| 16:45 | <smaug____> | annevk: but during cloning or right after? |
| 16:45 | <richt> | annevk: yes. |
| 16:45 | <annevk> | smaug____: during, but I see how that would be problematic |
| 16:46 | <annevk> | richt: hey, I have some other questions I'd like to ask |
| 16:46 | <annevk> | mostly relaying from sicking |
| 16:46 | <annevk> | richt: can "content" playback tell apart the user pressing pause and transient-solo happening? |
| 16:47 | <richt> | annevk: not currently, no. |
| 16:47 | <richt> | annevk: deliberately so that "content" playback respects the transient-solo interruption. |
| 16:47 | <annevk> | richt: e.g. if the user presses pause we'd like for the app to indicate in its controls that the user can resume |
| 16:47 | <annevk> | richt: but with transient-solo the app would want to disable its own controls |
| 16:48 | <annevk> | richt: it seems we have to enforce that interruption at a higher level either way |
| 16:50 | <annevk> | richt: I filed https://github.com/whatwg/mediasession/issues/89 to track this |
| 16:51 | <richt> | annevk: it's a good question. let's discuss further on gh. |
| 19:08 | <wanderview> | JakeA: annevk: sanity check me please... a service worker script itself (an its importScripts()) should not be able to be intercepted, right? |
| 19:12 | <JakeA> | wanderview: correct, they shouldn't |
| 19:12 | <wanderview> | JakeA: I'm glad you survived your train ride |
| 19:13 | <wanderview> | and thanks |
| 19:18 | <JakeA> | I only just survived. I'm all out of sweat that's for sure. |
| 21:17 | <Krinkle> | JakeA: Is there a way to inspect CacheStorage/window.caches visually in Chrome? (akin to the other Resources) |
| 21:23 | <JakeA> | Krinkle: yes, in the resources tab |
| 21:24 | <Krinkle> | Hm.. perhaps under a few layers of experimental options? |
| 21:24 | <JakeA> | Krinkle: might only be in beta/Canary |
| 21:24 | Krinkle | tries Chromium instead of canary |
| 21:24 | <Krinkle> | Canary is my defualt |
| 21:24 | <JakeA> | Krinkle: but yeah, enable the devtools experiments flag |
| 21:25 | <Krinkle> | Ha, got it. |
| 21:25 | <Krinkle> | I had one random window open in Chrome stable |
| 21:25 | <Krinkle> | the one I happened to be using the console of |
| 21:25 | <Krinkle> | :) |
| 21:26 | <Krinkle> | Yeah,it's there in canary. great. |
| 21:30 | <Krinkle> | JakeA: You mentioned there were security concerns about exposing caches on window. You reckon that may realistically result in it being withdrawn? |
| 21:30 | <Krinkle> | I'm seeing a benefit in being able to populate caches on the first hit when SW isn't active yet. |
| 21:35 | <JakeA> | Krinkle: I think it'll stay. Worst comes to the worst, you can postmessage to your installing worker telling it to cache some stuff |
| 21:35 | <Krinkle> | JakeA: Yeah. |
| 21:45 | <Krinkle> | While somewhat "uncool", we're also looking into trying without SW. Just being honest. |
| 21:45 | <Krinkle> | We don't need the 'fetch' event from SW as requests go via our loader function. SW also means we have to re-create large parts of the loader function to know which requests to ignore. |
| 21:46 | <Krinkle> | From window we can populate and access cache. This does necessitate indirect eval, but localStorage does that already now :-/ |
| 21:46 | <Krinkle> | Without SW, it won't work offline. But, working offline won't work anyway until other infrastructure adapts. Getting SW right as the first puzzle piece for offline would be cool, but we're looking to get big performance gains first. Offline is not our team's objective :( |
| 22:07 | <smaug____> | zcorpan: so resize event |
| 22:07 | <smaug____> | I couldn't land the patch implementing the behavior the spec has |
| 22:07 | <smaug____> | since it regresses performance |
| 22:08 | <smaug____> | this is the generic issue that too much stuff is happening around animation frame tick |
| 22:09 | <smaug____> | if an event listener takes much time, updating the graphics may be postponed too much |
| 22:11 | <zcorpan> | smaug____: ywah? |
| 22:13 | <zcorpan> | smaug____: ok. the relative order of things is in the html spec, so file a bug for hixie |
| 22:14 | <smaug____> | zcorpan: the issue is that I don't really have any good proposal how resize handling should be spec'ed |
| 22:14 | <zcorpan> | smaug____: file a bug anyway describing the problem :-) |
| 22:15 | smaug____ | files |
| 22:16 | <smaug____> | I think I filed a separate, but related bug to have a way to say a callback should be called after animation frame tick |
| 22:20 | <zcorpan> | i need to sleep now. will be offline for some more weeks |
| 22:21 | <zcorpan> | file bugs or send me email for anything i should look at later :-) |
| 22:25 | <smaug____> | he left, but https://www.w3.org/Bugs/Public/show_bug.cgi?id=28876 |