| 05:41 | <MikeSmith> | today’s winner: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/kDq4t93zbpA/KX9aZlbLBwAJ |
| 05:41 | <MikeSmith> | hope he takes in interest in <keygen> |
| 05:42 | <MikeSmith> | “fake news story about functionality that very much needs to be true” |
| 06:16 | <Domenic> | botie: tell zcorpan that the problem with the "Note:" bug is that we'd need some kind of override in standard.css to not insert the generated content... or we'd need to update all the specs at once. |
| 06:16 | <botie> | will do |
| 06:16 | <Domenic> | MikeSmith: isn't that the same guy that got kicked off a bunch of service worker repos? |
| 06:17 | <MikeSmith> | Domenic: yup |
| 06:17 | <MikeSmith> | making new friends now |
| 06:17 | <Domenic> | oh wow I scrolled up |
| 06:17 | <Domenic> | he sent a ... fake intent to implement ... |
| 06:18 | <MikeSmith> | gotta be a first |
| 06:18 | <MikeSmith> | breaking new ground every where he goes |
| 06:18 | <MikeSmith> | the Johnny Appleseed of techno-boors |
| 06:20 | <MikeSmith> | in other news we need a review for BroadcastChannel tests PR https://github.com/w3c/web-platform-tests/pull/4237 |
| 06:21 | <MikeSmith> | if anybody on teh channel is interested in helping the web-platform-tests effort that would be good PR for review as far as reviewing goes |
| 06:21 | <MikeSmith> | especially if you are already familiar with BroadcastChannel |
| 06:22 | <MikeSmith> | PR by Mek |
| 06:50 | <Domenic> | MikeSmith: aren't they already reviewed upstream? |
| 06:50 | <MikeSmith> | oh |
| 06:50 | <MikeSmith> | maybe so |
| 06:50 | <MikeSmith> | if so that would be great |
| 06:50 | MikeSmith | checks |
| 06:50 | <MikeSmith> | d’oh |
| 06:50 | <MikeSmith> | yeah |
| 06:51 | <MikeSmith> | first word in the commit message |
| 07:17 | <botie> | zcorpan, at 2016-11-29 06:16 UTC, Domenic said: the problem with the "Note:" bug is that we'd need some kind of override in standard.css to not insert the generated content... or we'd need to update all the specs at once. |
| 07:51 | <annevk> | MikeSmith: whoa, makes me wish Mark Pilgrim was still writing |
| 08:10 | <annevk> | zcorpan: added Oxford Comma to https://wiki.whatwg.org/wiki/Style |
| 08:47 | <younder> | Like the bit " stalkers, estranged spouses, and marketeers will no longer be allowed to track users covertly" :) |
| 08:49 | <younder> | Response to link https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/kDq4t93zbpA/KX9aZlbLBwAJ |
| 09:04 | <zcorpan> | Domenic: we have bikeshed.css |
| 09:05 | <zcorpan> | but if the idea is that generated content shouldn't be used for this, i suppose it shouldn't be used for bikeshedded specs, either |
| 09:06 | <zcorpan> | TabAtkins: ^ (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=28555 ) |
| 09:09 | <zcorpan> | i don't know if it causes an actual problem for users though. generated content is exposed in the acc tree in all browsers but IE11 per http://ljwatson.github.io/decks/2016/cssday/ and http://tink.uk/accessibility-support-for-css-generated-content/ |
| 09:09 | <zcorpan> | (i guess IE <= 11) |
| 10:32 | <annevk> | zcorpan: given you resolved the rendering issue for list items, is https://www.w3.org/Bugs/Public/show_bug.cgi?id=27185 WONTFIX? |
| 10:33 | <zcorpan> | annevk: without impl interest, i'd say so |
| 10:34 | <annevk> | Oh wait, I already marked it as such back in March |
| 11:39 | <daleharvey> | hmm am I missing something, <img style="width:25px; height: 25px" srcset="red-50.png 50w, green-100.png 100w, blue-150.png 150w" /> always comes out blue? |
| 11:41 | <zcorpan> | daleharvey: sizes defaults to 100vw. and chrome will stick to the largest one it has already loaded in srcset if you later shrink the viewport |
| 11:43 | <daleharvey> | Not sure why that means I am not getting the expected src, I am not shrinking the viewport, and I have a size set for each stc so default shouldnt apply? |
| 11:43 | <daleharvey> | *src |
| 11:44 | <zcorpan> | daleharvey: maybe you want sizes="25px" |
| 11:45 | <zcorpan> | daleharvey: the algorithm ignores your style attribute. you need to declare intended size with the sizes attribute |
| 11:50 | <daleharvey> | zcorpan: ah, thats great thanks a lot |
| 11:50 | <zcorpan> | daleharvey: np |
| 12:43 | <jamesanderson> | good afternoon; i am looking for a place to enquire about the proper way to use eventsource/server-side-event in practice. is this a good place? |
| 12:48 | <nox> | zcorpan: Your document.write test is amazing. |
| 12:49 | <annevk> | jamesanderson: depends on the question |
| 12:53 | <jamesanderson> | the first one: why do the clients not support setting the actual content media type and how do applications work around that? |
| 12:54 | <zcorpan> | nox: did it reveal some crash bug or so? :-) |
| 12:55 | <jamesanderson> | the second one: what is the intended way for a server to indicate there is nothing more in the stream. my initial encounter with the client implementation in firefox and safari indicates, if the caller does not close the connection, the requests are repeated indefinitely. |
| 12:57 | <annevk> | jamesanderson: why does the client have to set the MIME type? |
| 13:02 | <annevk> | jamesanderson: indicating the stream is done is something you have to implement yourself, e.g., by sending some kind of close frame |
| 13:02 | <annevk> | jamesanderson: you can also use a status code other than 200 to make the subsequent request fail |
| 13:03 | <annevk> | tobie: posted another PR for IDL's dfn tragedy |
| 13:03 | <annevk> | tobie: very small |
| 13:04 | <jamesanderson> | other than 200 sounds mean. i have to think about that, but as relentless as the safari and firefox libraries are, i do not want to leave it to the application. |
| 13:06 | <jamesanderson> | the effective content media type is to indicate how the application wants the data encoded. the obvious place would be a media type parameter, but the libraries do not permit that. |
| 13:06 | <jamesanderson> | other than two hundred also means that the server would have to retain request history, to known that there is a previous/next request relationship. |
| 13:08 | <annevk> | jamesanderson: the future of this is going to be fetch() and using the streams API on the Response object; EventSource is somewhat legacy though better supported at this point |
| 13:08 | <annevk> | jamesanderson: but yeah, you'll have to do some bookkeeping |
| 13:08 | <annevk> | jamesanderson: still not really sure what you mean by "effective content media type" |
| 13:12 | <jamesanderson> | my situation is a streaming sparql endpoint. a client customarily specifies how they want the result encoded. for which, something like "text/event-stream; accept=application/sparql-results+json" would make sense, despite that the registration permits no parameter. |
| 13:14 | <annevk> | jamesanderson: you mean in the Accept header? |
| 13:14 | <annevk> | jamesanderson: but yeah, that's not possible |
| 13:14 | <annevk> | jamesanderson: that kind of stuff is all possible with fetch(), but as I mentioned support for that is worse |
| 13:14 | <jamesanderson> | exactly. the eventsource code which i have found has the accept header value hard-coded. |
| 13:15 | <annevk> | jamesanderson: and you'd have to write your own framing code with fetch(), it's a little lower level |
| 13:16 | <jamesanderson> | the point of eventsource was to avoid that, so that would be a shame. |
| 13:16 | <annevk> | It's a tradeoff, you can go with EventSource, but you have to accept it's limited |
| 13:16 | <jamesanderson> | emiiting an eventsource strem actually does involve some degree of framing, but the client side need not. |
| 13:17 | <annevk> | You can go with fetch(), but you have to accept you need to do more work and not all browsers support it well |
| 13:17 | <jamesanderson> | so, wrt media type, what do people do? just presume something and hope? |
| 13:17 | <annevk> | That is, I think at this point it's basically Chrome that does fetch() and streams, but maybe Edge? |
| 13:18 | <annevk> | jamesanderson: I would expect EventSource to be mostly used for tightly-coupled applications |
| 13:18 | <annevk> | jamesanderson: where the server and client library are written by the same team and no variance is needed |
| 13:18 | <jamesanderson> | oh. cool. |
| 13:19 | <jamesanderson> | good to know, what to make of it. |
| 13:20 | <jamesanderson> | that is, good for an immediate demo, but do not count on it for general use. |
| 13:23 | <annevk> | The future here is clearly fetch(), but you'll have to figure out how to get there I'm afraid |
| 13:34 | <jamesanderson> | thank you for the insights. |
| 13:42 | <annevk> | smaug: history is the worst |
| 13:42 | <annevk> | smaug: history/navigation |
| 13:42 | <smaug> | tell me something new :) |
| 13:42 | <botie> | will do |
| 13:43 | <annevk> | smaug: location.hash = "forward", does not refresh the page; then history.back() does not either; then refresh the page; then history.forward(), does refresh the page?! |
| 13:44 | <annevk> | smaug: also, in Chrome location.hash = "forward" does not count as a new history entry |
| 13:44 | <smaug> | really |
| 13:44 | <smaug> | huh |
| 13:44 | <smaug> | does it count in UI? |
| 13:44 | <annevk> | smaug: if you do history.back() after that you end up on about:blank |
| 13:44 | <smaug> | but not in history API? |
| 13:44 | <annevk> | smaug: dunno, haven't tested the difference |
| 13:44 | <annevk> | I wasn't even testing that |
| 13:44 | <annevk> | I am trying to test if same-URL loading deletes forward history |
| 13:45 | <annevk> | And then I found myself getting dragged into all kinds of other messes |
| 13:47 | <annevk> | smaug: do we mess around with sessionStorage when traversing in history? |
| 13:47 | <annevk> | smaug: I think we do, since I just created an infinite loop |
| 13:49 | <annevk> | Ooh, wait, maybe that's my bad |
| 13:49 | <smaug> | mess with sessionStorage? I don't think so. If we end up re-loading something, that might be different, but session history itself doesn't know anything about sessionStorage |
| 13:52 | <annevk> | smaug: Chrome does the same through UI |
| 13:53 | <annevk> | smaug: <script>location.hash = "blah"</script> then either UI back or history.back() takes you to about:blank |
| 13:54 | <smaug> | annevk: but if you have a page with #fragments, and click those, new session history entry is created |
| 13:54 | <smaug> | in chrome, as far as I know |
| 13:54 | smaug | tests |
| 13:55 | <annevk> | smaug: yeah |
| 13:55 | <annevk> | seems like it anyway |
| 13:55 | <botie> | i think seems like it is coming back now? |
| 13:55 | <annevk> | botie: stop |
| 13:55 | <botie> | annevk: sorry... |
| 13:56 | <annevk> | smaug: maybe in Chrome they guard this with user gestures or something? |
| 13:57 | <smaug> | how would that be web compatible... |
| 13:58 | <annevk> | smaug: yeah, it's not true |
| 13:58 | <annevk> | smaug: if you do <a>.click() it also adds an entry |
| 13:59 | <annevk> | smaug: seems like this might just be a bug with location since it's not consistent at all |
| 14:04 | <nox> | zcorpan: Do you get an exception in Gecko through the rendered view too? I don't. |
| 14:30 | <wanderview> | JakeA: ping |
| 14:30 | <JakeA> | wanderview: hey! |
| 14:30 | <wanderview> | JakeA: got a minute for a SW spec question? |
| 14:30 | <JakeA> | wanderview: yeah, I'm actually sat at a desk and a laptop for once |
| 14:31 | <wanderview> | wow... ok! |
| 14:31 | <wanderview> | JakeA: so we are implementing the "use no-cache by default on updates" thing in gecko and a question arose |
| 14:32 | <wanderview> | the issue defines an API like register(scriptURL, { useCache: true }) |
| 14:32 | <wanderview> | the spec also short circuits registration if the scriptURL and scope are the same as an existing registration |
| 14:32 | <wanderview> | our question is, should that short circuit still happen even if the "useCache" value has changed? |
| 14:33 | <wanderview> | or should there be another way for a service worker to change its "useCache" value? |
| 14:33 | <wanderview> | JakeA: ^^^ |
| 14:34 | <wanderview> | I'm inclined to implement without any ability to change useCache to start, but thought I would get your opinion |
| 14:34 | <JakeA> | wanderview: changing the value of useCache in .register feels like the right way to update this value |
| 14:35 | <JakeA> | wanderview: whether it causes an immediate refetch of the SW (like changing the url does) is another question |
| 14:35 | <wanderview> | JakeA: so the bypass check should be "if script URL, scope, and useCache value are identical, then bypass" ? |
| 14:35 | <JakeA> | wanderview: yeah |
| 14:35 | <wanderview> | ok |
| 14:36 | <wanderview> | JakeA: it would be easiest if it just acted the same as if a script URL changed |
| 14:36 | <JakeA> | wanderview: that works for me then |
| 14:36 | <wanderview> | JakeA: ok, thanks... I'll update the github issue |
| 14:37 | <JakeA> | wanderview: btw I've been working on cleaning up the spec. Hopefully making changes from now on will be a lot easier. I'm also taking a break from speaking in 2017 so will in theory have more time to actually, y'know, contribute |
| 14:37 | <wanderview> | nice! |
| 14:43 | <wanderview> | JakeA: oh, looks like I had a couple other questions about this here: https://github.com/w3c/ServiceWorker/issues/893#issuecomment-260442769 |
| 14:44 | <wanderview> | like, should we expose a getter for useCache |
| 14:46 | <JakeA> | wanderview: ugh, sorry I didn't answer that. I'm still recovering from CDS I think |
| 14:46 | <wanderview> | np |
| 14:46 | <zcorpan> | nox: the too deep counter should be a variable of the HTML parser, like the script nesting level, correct? |
| 14:46 | <wanderview> | JakeA: I think I was thinking it was less part of the registration identity (scope/scriptURL) and more something that could changed on the registration (like push subscription) |
| 14:47 | <JakeA> | wanderview: yeah, it could go either way. But it feels most like the scriptURL to me |
| 14:48 | <wanderview> | JakeA: so a new version of the SW script should not be able to change it? |
| 14:49 | <JakeA> | wanderview: it could call navigator.serviceWorker.register() in its install step |
| 14:49 | <wanderview> | JakeA: navigator.serviceWorker.register() is exposed in the worker context? |
| 14:50 | <JakeA> | wanderview: yep! |
| 14:50 | <wanderview> | I don't think we implement that |
| 14:52 | <beverloo> | I don't think we do either |
| 14:54 | <JakeA> | huh, so we don't |
| 14:55 | <JakeA> | It's specifically added to NavigatorWorker https://w3c.github.io/ServiceWorker/#navigator-serviceworker |
| 14:55 | <JakeA> | um, WorkerNavigator |
| 14:55 | <wanderview> | JakeA: workers are not well implemented for SWs yet... I don't think either browser exposes Worker Client objects either |
| 14:56 | <wanderview> | JakeA: and in gecko we don't even expose ServiceWorker in worker context yet... self.registration.active is always null in gecko at the moment |
| 14:56 | <JakeA> | ohhh interesting |
| 14:57 | <wanderview> | we've had surprisingly few compat issues from that |
| 15:00 | <wanderview> | I had one report where someone wanted to check self.registration.active.scriptURL... but I was able to point them to self.location |
| 15:00 | <annevk> | Ms2ger: way to go finding so many issues by just looking at origin |
| 15:00 | <wanderview> | JakeA: s/setter/getter/ in your github comment? |
| 15:01 | <JakeA> | oh ffs why do they even let me near computers |
| 15:01 | <JakeA> | wanderview: fixed! |
| 15:01 | <MikeSmith> | .win 22 |
| 15:01 | <MikeSmith> | bah |
| 15:01 | <wanderview> | JakeA: oh, I didn't realize I could edit your post... (or the button in the UI suggests I can) |
| 15:01 | <annevk> | Ms2ger: slowly realizing that while what Hixie created is much better than HTML4, we need to be much better than that still |
| 15:02 | <annevk> | Ms2ger: and the lack of review on these features is just astonishing |
| 15:02 | <annevk> | Ms2ger: all these other APIs that get added must do pretty poorly |
| 15:03 | <Ms2ger> | Yeah :/ |
| 15:06 | <nox> | zcorpan: Probably. |
| 15:07 | <zcorpan> | nox: are you interested in making a PR for the spec? :-) |
| 15:07 | <nox> | Not really. :P |
| 15:07 | <nox> | zcorpan: Though, |
| 15:07 | <nox> | zcorpan: do you think the spec could use a refactoring getting rid of insertion point? |
| 15:09 | <zcorpan> | nox: no, i think that seems like it would risk introducing regressions and it wouldn't fix any known problem, would it? |
| 15:09 | <nox> | Nah. |
| 15:44 | <nox> | zcorpan: Didn't try your stuff in Servo yet btw, |
| 15:44 | <nox> | zcorpan: I said "amazing" because I wouldn't even have tried to see if later calls get neutered or not. |
| 15:46 | <zcorpan> | nox: ah :-) |
| 15:48 | <annevk> | jgraham: so I have tests that are nearly ready but I need help with making the origin bits generic |
| 15:48 | <annevk> | jgraham: is it best to submit a PR or create a branch? |
| 15:58 | <Ms2ger> | PR, I think |
| 15:58 | <Ms2ger> | Harder to get lost |
| 15:58 | <annevk> | I'm going with that |
| 15:58 | <annevk> | Since I need to leave soonish too |
| 15:59 | <wanderview> | JakeA: have you guys had any compat issues from the no-fetch optimizations shipping in chrome 54? |
| 16:00 | <JakeA> | wanderview: none that I'm aware of |
| 16:00 | <Ms2ger> | Spec says "When an iframe element is removed from a document, the user agent must discard the element's nested browsing context," |
| 16:00 | <Ms2ger> | What should happen to descendants of the discarded BC? |
| 16:03 | <annevk> | Ms2ger: isn't that defined in "discard"? |
| 16:03 | <Ms2ger> | Doh |
| 16:04 | <annevk> | Ms2ger: it's a little vague since according to that a browsing context doesn't have child browsing contexts, it's associated document does, but we do talk about a browsing context's nested browsing contexts now and then |
| 16:05 | <annevk> | Ms2ger: maybe the latter is actually bad practice and we shouldn't do things like that |
| 16:06 | <annevk> | igrigorik: for https://github.com/whatwg/fetch/pull/419 it'd be good to have a test plan as well |
| 16:06 | <annevk> | igrigorik: we basically want to have a corresponding test for each WHATWG Standard change |
| 16:07 | <annevk> | igrigorik: puts the bar a little higher, but the thinking is that interop will come faster too |
| 16:07 | <Ms2ger> | annevk, meet ajeffrey_, who's prompting my questions :) |
| 16:07 | <annevk> | I think we met in London |
| 16:07 | ajeffrey_ | waves |
| 16:08 | annevk | waves back |
| 16:08 | <ajeffrey_> | annevk: we did indeed |
| 16:08 | <annevk> | Unfortunately, I gotta go pick up the kid |
| 16:08 | <ajeffrey_> | was it something I said? :) |
| 16:08 | <annevk> | Nah, it's more that I'm already a little late |
| 16:09 | <annevk> | Anyway, let me apologize for the state of the lifecycle affair of all these objects |
| 16:09 | <annevk> | It's pretty awful |
| 16:09 | <annevk> | I have hopes of improving the situation, but the complexity is somewhat daunting |
| 16:12 | <wanderview> | JakeA: I still wish we could add an explicit fetch event subscription API that gets rid of this weird quirk mode with addEventListener() throwing |
| 16:12 | <ajeffrey_> | Am I right in reading https://html.spec.whatwg.org/multipage/browsers.html#a-browsing-context-is-discarded |
| 16:13 | <ajeffrey_> | as saying that when a browsing context is discarded, its document is discarded, |
| 16:13 | <wanderview> | JakeA: if you call registration.sendMeFetchPlease(true) then you can call addEventListener('fetch') async, etc |
| 16:13 | <ajeffrey_> | even if there are other strong references to it? |
| 16:13 | <JakeA> | wanderview: *scratches head* what's the benefit? |
| 16:14 | <wanderview> | JakeA: if you want to work with a sane API you can choose to do so... we only do weird quirk stuff if you aren't explicit about fetch event handling on the registration |
| 16:15 | <wanderview> | JakeA: just my christmas wish... but I'm happy not to re-litigate the no-fetch issue |
| 16:16 | <JakeA> | wanderview: creating the listeners async is going to fail though |
| 16:16 | <JakeA> | once the service worker is shut down, the listener is gone |
| 16:18 | <wanderview> | JakeA: I guess it would be difficult to use without some sort of sync state the SW could use |
| 16:19 | <wanderview> | JakeA: although still possible... the page could postMessage('doSpecialFetch') to the SW and then perform a network call... the message event listener could register the fetch event listener |
| 16:20 | <JakeA> | feels really hacky |
| 16:20 | <wanderview> | yes |
| 16:20 | <wanderview> | JakeA: but so does making addEventListener() throw for async registrations... but not throwing for random addeventlistener in script evaluation |
| 16:21 | <JakeA> | wanderview: random as in Math.random? |
| 16:21 | <wanderview> | JakeA: anyway... it just feels like an explicit API could avoid all the special logic |
| 16:21 | <wanderview> | JakeA: yes... Math.random |
| 16:21 | <wanderview> | JakeA: or "only on tuesdays" |
| 16:22 | <wanderview> | just think of the potential of different fetch event handlers for every day of the week! |
| 16:22 | <JakeA> | haha |
| 16:22 | <wanderview> | JakeA: I agree there aren't a lot of use cases... but its just a code smell adding these special cases to addEventListener()... |
| 16:22 | <wanderview> | and onfetch= |
| 16:23 | <JakeA> | wanderview: I think it's a big of implementation ugliness but works pretty well for developers |
| 16:23 | <wanderview> | JakeA: does chrome let you do setTimeout(_ => self.onfetch = null, 0) ? |
| 16:28 | <zcorpan> | annevk: wouldn't an opaque origin mean that the script is not allowed to access anything in the document (e.g. to clone a node)? |
| 16:30 | <JakeA> | wanderview: just tried it and it didn't complain |
| 16:32 | <wanderview> | JakeA: is chrome supposed to be complaining about async fetch event handlers? |
| 16:34 | <wanderview> | JakeA: I can do setTimeout(_ => addEventListener('fetch'), 0) without warning in chrome |
| 16:34 | <wanderview> | and without throwing |
| 16:34 | <JakeA> | wanderview: I'm getting a warning when I try it in the console |
| 16:34 | <JakeA> | but yeah it should be a throw |
| 16:35 | <wanderview> | JakeA: maybe its just a warning after install? |
| 16:36 | <wanderview> | JakeA: ah, canary warns, but but chrome stable does not |
| 16:36 | <JakeA> | wanderview: ahh so it's relatively new |
| 16:36 | <JakeA> | it should really throw though |
| 16:38 | <wanderview> | JakeA: not throwing might explain why no compat complaints so far |
| 16:39 | <wanderview> | JakeA: I think we will probably implement what chrome implements here to start... to avoid web compat issues |
| 16:40 | <wanderview> | unless you think throwing might be added soon |
| 16:41 | <JakeA> | wanderview: matching Chrome seems fair. I'll create an issue and a test case to get Chrome doing the right thing |
| 16:42 | <wanderview> | JakeA: here is the issue for the warning: https://bugs.chromium.org/p/chromium/issues/detail?id=594160 |
| 16:43 | <wanderview> | JakeA: and do you think we should throw for all async addEventListener() calls or just for async addEventListener('fetch') calls? |
| 16:43 | <JakeA> | wanderview: oh, the spec actually says to warn rather than throw |
| 16:43 | <JakeA> | my bad |
| 16:43 | <wanderview> | hmm |
| 16:44 | <wanderview> | JakeA: I thought we agreed to change that in the no-fetch issue |
| 16:44 | <JakeA> | wanderview: ohhh I think it might be in the dom spec |
| 16:44 | <wanderview> | right |
| 16:44 | <JakeA> | wanderview: https://dom.spec.whatwg.org/#dom-eventtarget-addeventlistener |
| 16:44 | <wanderview> | JakeA: it was added for *all* addEventListener() calls... even things like 'error'... that seems wrong to me |
| 16:45 | <JakeA> | wanderview: https://github.com/whatwg/dom/issues/371#issuecomment-261251184 |
| 17:03 | <annevk> | zcorpan: I don't think so |
| 17:03 | <annevk> | zcorpan: I don't think any of those checks use the origin of a document object |
| 17:04 | <zcorpan> | annevk: ok |
| 17:04 | <annevk> | ajeffrey_: yeah, I think that's correct |
| 17:04 | <annevk> | ajeffrey_: I'm around for a bit now if you have some questions |
| 17:04 | <annevk> | (no promises on answers though) |
| 17:04 | <ajeffrey_> | annevk: cool |
| 17:05 | <ajeffrey_> | OK, so the idea is that a document can be discarded even if there is a strong reference to it. |
| 17:05 | <ajeffrey_> | can it ever be undiscarded? |
| 17:06 | <annevk> | ajeffrey_: I don't think so |
| 17:06 | <ajeffrey_> | e.g. if an iframe is detatched from the document tree then reattatched? |
| 17:06 | <ajeffrey_> | annevk: I think you're right, |
| 17:07 | <ajeffrey_> | when the iframe is reattatched, it gets a new document object. |
| 17:07 | <annevk> | ajeffrey_: definitely not then, we'd create a new browsing context and document |
| 17:07 | <annevk> | ajeffrey_: and since salvageable is set to false I'm pretty sure it won't ever reappear |
| 17:07 | <ajeffrey_> | does this happen if the iframe is moved inside the same document? |
| 17:07 | <annevk> | ajeffrey_: yes |
| 17:08 | <ajeffrey_> | okay, and the disposing of documents is synchronous, isn't it? |
| 17:08 | <annevk> | ajeffrey_: <iframe> is one of the reasons we can't really do transactions with the tree |
| 17:08 | <annevk> | ajeffrey_: yeah, creation is too |
| 17:09 | <ajeffrey_> | the case which is going to cause servo grief is where you have nested iframes |
| 17:09 | <annevk> | ajeffrey_: collection of the underlying objects can be async of course |
| 17:09 | <ajeffrey_> | A contains B contains C, |
| 17:09 | <ajeffrey_> | and A and C are same-origin, |
| 17:09 | <annevk> | ajeffrey_: do you have cross-process <iframe>? |
| 17:10 | <annevk> | ajeffrey_: I guess you want to study whatever Chrome is doing |
| 17:10 | <ajeffrey_> | then A detatches B, and should immediately be able to observe that C is detatched. |
| 17:10 | <ajeffrey_> | annevk: cross-thread, yes. |
| 17:10 | <annevk> | ajeffrey_: A can already get sync access to C though |
| 17:10 | <ajeffrey_> | in the case above, A and C will be in a different thread than B. |
| 17:11 | <ajeffrey_> | annevk: indeed, that's what's causing the problem, |
| 17:11 | <ajeffrey_> | we need to provide some way for the script thread for A+C to be synchronously informed that the discard has happened, |
| 17:11 | <annevk> | ajeffrey_: maybe foolip has insights into how Chrome does that |
| 17:12 | <ajeffrey_> | even though it's a different thread that takes care of it :/ |
| 17:12 | <annevk> | ajeffrey_: but you basically need some kind of proxying and script halting I suppose |
| 17:12 | <ajeffrey_> | annevk: yes, we are probably going to have to block the script waiting for the discards to happen, |
| 17:13 | <ajeffrey_> | we just need to make sure that we don't have a possibility for deadlock because of this. |
| 17:13 | <ajeffrey_> | Does chrome keep all the iframes for one tab in the same process? |
| 17:15 | <annevk> | ajeffrey_: I think they might at the moment, but they have an OOP-iframe project going on |
| 17:15 | <annevk> | ajeffrey_: http://www.chromium.org/developers/design-documents/oop-iframes |
| 17:16 | <ajeffrey_> | annevk: ah, thanks for the pointer! |
| 17:16 | ajeffrey_ | goes and reads |
| 17:18 | <ajeffrey_> | hmm, no mention of document and browsing context discarding there, I wonder how that'll be handled? |
| 17:26 | <annevk> | ajeffrey_: yeah weird, dunno |
| 17:28 | <ajeffrey_> | I think I can see how to do it in servo. Thanks! |
| 17:29 | <annevk> | \o/ |
| 17:30 | <annevk> | zcorpan: help me out here, is test((t) => { t.add_cleanup() what you mean? |
| 17:31 | <zcorpan> | annevk: yes |
| 17:35 | <zcorpan> | annevk: setting to the empty string does nothing :-D but i can try to fix it |
| 17:36 | <annevk> | zcorpan: does nothing? |
| 17:36 | <annevk> | zcorpan: ooh, the setter is super weird? hmm |
| 17:36 | <zcorpan> | yeah |
| 17:36 | <annevk> | can it even be fixed then if every set is effectively a new cookie header? |
| 17:39 | <zcorpan> | there are tests that deal with cookies and clean them up. i'll check |
| 17:41 | <zcorpan> | websockets/cookies/001.html |
| 17:43 | <zcorpan> | it uses a random cookie name because tests can be run in parallel in the same browser instance, which would affect the result if it runs 2 cookie tests with the same cookie name |
| 17:43 | <annevk> | zcorpan: that does seem a lot purer |
| 17:43 | <annevk> | zcorpan: I guess I can try something like that later |
| 17:45 | <zcorpan> | annevk: also there's the template document's cookie, but i don't know if it really needs a cleanup |
| 17:46 | <annevk> | zcorpan: it probably should though it would only affect non-conforming UAs |
| 17:46 | <zcorpan> | yeah |
| 18:58 | <foolip> | ajeffrey_, annevk, I know mostly about fullscreen, but in ABA origin nesting cases, there's code that traverses the frame tree to find all of the local frames ("browsing contexts") and do stuff with them in the same task, while doing the things in B in another process. |
| 18:59 | <foolip> | ajeffrey_: If you need it, I can find someone who knows more about out-of-process iframes for you to interrogate. |
| 19:00 | <ajeffrey_> | foolip: do you keep a cached copy of the frame tree in each process? |
| 19:00 | <foolip> | ajeffrey_: yes, each process has its own view of all frames |
| 19:00 | <foolip> | In Blink this is the Frame/LocalFrame/RemoteFrame split |
| 19:00 | <ajeffrey_> | foolip: yes, that would work too. |
| 19:00 | <foolip> | and some other things are also split into Local/Remote |
| 19:01 | <ajeffrey_> | we're trying not to duplicate data in servo, |
| 19:01 | <ajeffrey_> | so there's only one process which keeps track of the whole frame tree. |
| 19:02 | <foolip> | ajeffrey_: but there must at least be a way to synchrously ask some questions about the parent frame? Without that you can't implement the Fullscreen allowfullscreen checks and probably many other things. |
| 19:02 | <ajeffrey_> | there's an annoying tradeoff of messaging vs cache coherency here :( |
| 19:03 | <ajeffrey_> | foolip: yes, for things which have to be synchronous across processes, we use messaging. |
| 19:03 | <foolip> | ajeffrey_: is it only ever synchronous in the child-parent direction? otherwise, deadlocks? |
| 19:04 | <ajeffrey_> | foolip: there's a coordinating process (the "constellation") that script is allowed to block on, |
| 19:04 | <ajeffrey_> | otherwise like you say, deadlock. |
| 19:50 | <foolip> | ajeffrey_: ok, will be interesting to see if it's possible to do it everything this way, or if there are web compat contraints that break the whole model |
| 19:50 | <foolip> | (hope not) |
| 19:51 | <ajeffrey_> | foolip: indeed. |
| 19:52 | <ajeffrey_> | foolip: it's an interesting challenge adding concurrency to a model that was designed to be single-threaded. |
| 21:51 | <ajeffrey_> | annevk: in the WebIDL for Window https://html.spec.whatwg.org/multipage/browsers.html#window should parent and top have type WindowProxy? since they can return null? |
| 21:55 | <Domenic> | ajeffrey_: yes definitely; file an issue? |
| 21:56 | <ajeffrey_> | Domenic: will do |
| 21:58 | <smaug> | why google.fi wants to use Flash o_O |
| 22:00 | <ajeffrey_> | Domenic: https://github.com/whatwg/html/issues/2115 |
| 23:54 | <MikeSmith> | another fake Intent to Implement https://groups.google.com/forum/#!topic/mozilla.dev.platform/1K_Uq_fx1l4 |
| 23:54 | <MikeSmith> | from another personality |