| 10:06 | <smaug> | why some people like js symbols? |
| 10:06 | smaug | hasn't seen the light why symbols are a good thing |
| 10:30 | <JakeA> | When creating an about:blank iframe, then navigating it, the global is preserved from the original about:blank. This is according to the spec, but only Firefox seems to implement this. |
| 10:31 | <JakeA> | Anyone know the history here? |
| 10:32 | <JakeA> | If Firefox is the only browser that does the weird replacement stuff, shouldn't Firefox change? |
| 11:21 | <smaug> | JakeA: I thought only webkit based browsers had the weird setup of not reusing global |
| 11:22 | <smaug> | JakeA: how does blink preverse event listeners when doing var w = window.open("sameorigin.html"); w.addEventListener("load", function() {}); |
| 11:23 | <smaug> | JakeA: that is, I believe, the biggest reason for reusing global |
| 11:23 | <smaug> | moving listeners to some other object would be super weird |
| 11:25 | <JakeA> | smaug: Yeah, load doesn't seem to fire for window.open in Chrome/Safari/Edge |
| 11:25 | <smaug> | wait, what? |
| 11:26 | <JakeA> | Unless I've done something really wrong http://output.jsbin.com/rofecit/quiet |
| 11:26 | <smaug> | you can't use window.open and observe when same origin page has been loaded? |
| 11:26 | <JakeA> | That appears to be the case |
| 11:27 | <JakeA> | It works with iframes via iframe.onload, which also do the replacement thing (in Firefox only) http://output.jsbin.com/bifelu/ |
| 11:27 | <smaug> | (loaded www.yle.fi and then) var w = window.open("http://www.yle.fi";); w.onload = function() { console.log("loaded"); }; |
| 11:27 | <smaug> | JakeA: that certainly prints loaded to console |
| 11:28 | <smaug> | JakeA: you're just doing window.open(); |
| 11:28 | <smaug> | that is very different case |
| 11:28 | JakeA | falls over |
| 11:29 | <JakeA> | I thought that would create a same-origin about:blank window that could later be replaced? |
| 11:29 | <smaug> | window.open(); doesn't load anything. it just creates initial about:blank |
| 11:30 | <smaug> | _creates_, not _loads_ |
| 11:30 | <JakeA> | Sure, but then when I navigate it |
| 11:31 | <smaug> | anyhow, var w = window.open("http://www.yle.fi";); w.onload = function() { console.log("loaded"); }; shows that blink does dispatch load |
| 11:31 | <JakeA> | …to a same origin URL I'd expect a load event, but only Firefox gives me that. Or have I stumbled on another different case? |
| 11:31 | <smaug> | but I don't understand why blink works with my testcase. The event listener is added before anything has been loaded |
| 11:32 | <smaug> | if it doesn't reuse the global, it somehow mysteriously moves listeners to another object? |
| 11:34 | <JakeA> | smaug: here's an example that doesn't use an empty url http://output.jsbin.com/bexuzaq/quiet |
| 11:48 | <smaug> | JakeA: and I see same stuff printed in chrome and ff |
| 11:48 | <smaug> | but why does chrome ever print "load fired" ? |
| 11:49 | <JakeA> | hmm yeah, my test is wrong |
| 11:50 | <smaug> | JakeA: what is the model blink has for event listeners? |
| 11:50 | <JakeA> | smaug: I guess it's doing something special for window.open(url), but I'm not sure what |
| 11:51 | <JakeA> | but it seems Safari & Edge do the same |
| 11:51 | <JakeA> | Given the results of http://output.jsbin.com/rofecit/quiet |
| 11:51 | <smaug> | JakeA: since if I do var w = window.open("https://www.yle.fi";); w.document.documentURI; also blink shows the uri is about:blank at that point |
| 11:52 | <smaug> | IIRC IE used to have same model as Netscape and then Gecko. (but my memory could be wrong here) |
| 11:56 | <JakeA> | smaug: http://output.jsbin.com/bifelu/quiet is weird. In Firefox .hello is "world" in both cases, unless I wait for onload before setting .hello |
| 11:57 | <JakeA> | I guess it's because the navigate happens before the first navigation completes |
| 11:57 | <smaug> | JakeA: iframes load about:blank, at least in gecko |
| 11:59 | <smaug> | looks like also blink loads about:blank there |
| 11:59 | <smaug> | I mean even without src attribute |
| 11:59 | <smaug> | global reuse happens only when initial (not loaded about:blank) is replaced with something else from the same origin |
| 12:10 | <JakeA> | "if the nested browsing context's session history contained only one Document when the process the iframe attributes algorithm was invoked, and that was the about:blank Document created when the nested browsing context was created, then any navigation required of the user agent in that algorithm must be completed with replacement enabled." |
| 12:11 | <JakeA> | smaug: so, you're saying Blink creates an about:blank iframe, then navigates it to about:blank? |
| 12:11 | <JakeA> | So it's the about:blank to about:blank navigation that happens with replacement enabled? |
| 12:12 | <smaug> | in gecko initial about:blank -> sameorigin page happens with reuse |
| 12:12 | <smaug> | not replacement |
| 12:12 | <smaug> | (or perhaps one could call it replacement too :) ) |
| 12:13 | <smaug> | JakeA: but I still mainly wonder how blink deals with event listeners |
| 12:13 | <JakeA> | I think I'll resign myself to never understanding this :D |
| 12:14 | <smaug> | FWIW, I think Gecko's model is reasonable sane, but I admit that I don't understand blink's model. Perhaps it is sane too. |
| 12:15 | <smaug> | (document.open after load event is also related and makes this even more complicated. ) |
| 12:17 | <JakeA> | I'm not sure there's a sensible solution here, but it sure is difficult to pick the least unexpected :D |
| 13:10 | <JakeA> | If I change the src of an iframe, what's the source browsing context? The parent of the iframe or the iframe itself? |
| 13:10 | <JakeA> | https://html.spec.whatwg.org/multipage/iframe-embed-object.html#otherwise-steps-for-iframe-or-frame-elements doesn't pass the source explicitly |
| 13:12 | <JakeA> | I'm assuming the source browsing context is the iframe if I do iframe.contentWindow.location.href = "…" |
| 13:26 | <yoav> | Hey! Are there known patterns/examples for defining an object and its processing in one spec and then operating on that object (processing it and e.g. adding new proprties to it) from another spec? |
| 13:29 | <wanderview> | JakeA: its not just gecko that implements reusing the global |
| 13:30 | <wanderview> | oh, you said navigating it |
| 13:31 | <JakeA> | wanderview: I guess I'm in a muddle when it comes to when the reuse happens & when it doesn't. I thought I'd see globals live when creating an iframe, waiting for it to load, then navigating it to somewhere same-origin |
| 13:31 | <wanderview> | JakeA: from my testing it depends on when you call .src in blink |
| 13:31 | <wanderview> | when you set .srv |
| 13:31 | <wanderview> | .src |
| 13:31 | wanderview | still drinking his coffee... |
| 13:31 | <wanderview> | JakeA: let me find the irc conversation with bz where we talked about it |
| 13:32 | <JakeA> | wanderview: this is the case that surprised me in Firefox http://output.jsbin.com/lawumuw/1/quiet |
| 13:33 | <JakeA> | wanderview: if I comment out that "await p" (as in don't wait for the load event), the global lives on |
| 13:35 | <wanderview> | JakeA: see scrollback here: http://logs.glob.uno/?c=mozilla%23content&s=14+Jun+2017&e=14+Jun+2017#c447305 |
| 13:35 | <wanderview> | JakeA: in chrome, if you do this: |
| 13:35 | <wanderview> | var f = document.createElement('iframe'); document.body.appendChild(f); f.contentWindow.foo = 'foo'; f.src = '?foo'; |
| 13:35 | <wanderview> | then: f.contentWindow.foo |
| 13:35 | <wanderview> | you get undefined |
| 13:36 | <wanderview> | but if you do this: |
| 13:36 | <wanderview> | var f = document.createElement('iframe'); f.src = '?foo'; document.body.appendChild(f); f.contentWindow.foo = 'foo'; |
| 13:36 | <wanderview> | then f.contentWindow.foo is "foo" |
| 13:36 | <wanderview> | JakeA: chrome has different behavior if you set .src before or after appending to the document |
| 13:37 | <JakeA> | haha |
| 13:37 | <JakeA> | wanderview: http://logs.glob.uno/?c=mozilla%23content&s=14+Jun+2017&e=14+Jun+2017#c447284 - this is exactly what I just ran into |
| 13:38 | <wanderview> | JakeA: my key take away from that irc log: http://logs.glob.uno/?c=mozilla%23content&s=14+Jun+2017&e=14+Jun+2017#c447305 |
| 13:38 | <JakeA> | Makes sense |
| 13:38 | <wanderview> | and thats why I tried to focus on in that about:blank test I wrote |
| 13:39 | <JakeA> | In a weird web way |
| 13:39 | <wanderview> | JakeA: I mean... it explains why we all have some kind of functionality here... thats the use case sites actually use |
| 13:40 | <JakeA> | yeah |
| 13:41 | <wanderview> | JakeA: at least in gecko I think we have a flag set on the about:blank that says its "initial"... and when the load event fires we set that flag false |
| 13:41 | <wanderview> | and we only re-use the global if the initial flag is set |
| 13:42 | <JakeA> | Yeah, that matches what I'm seeing in those jsbins |
| 13:42 | <wanderview> | JakeA: for example, I believe window.open() with no args should give you an initial about:blank that would be reused... but we have a known conflict with the spec where we mark it non-initial and don't reuse |
| 13:42 | <wanderview> | JakeA: I think there is some desire to fix this, but not sure this corner case has attracted much attention in the past |
| 13:44 | <JakeA> | wanderview: Ahh yes, that explains what I'm seeing in my other jsbin. But yeah, I don't think developers are hitting against this. I was just trying to see if browsers worked how I thought. |
| 13:45 | <JakeA> | The answer was "no". The answer is always "no".] |
| 13:45 | <JakeA> | :D |
| 13:45 | <wanderview> | JakeA: stuff like Clients API increases our exposure to these compat issues, though |
| 13:46 | <JakeA> | wanderview: I think your idea of initialClientId helps a lot. I think we should ditch reservedClientId in favour of it |
| 13:46 | <JakeA> | but maybe call it resultingClientId |
| 13:46 | <wanderview> | JakeA: uh... but we don't always have an initialClientId, right? |
| 13:46 | <wanderview> | oh |
| 13:46 | <wanderview> | you mean combine them |
| 13:46 | <JakeA> | yeah |
| 13:46 | <JakeA> | resultingClientId - the potentially-reserved client that will house the resulting document/worker. |
| 13:46 | <wanderview> | JakeA: how do you handle the difference in postMessage() behavior between them? |
| 13:47 | <wanderview> | that is my main concern with combining them |
| 13:47 | <JakeA> | wanderview: by the time you have the client, you can tell if it's .reserved or not |
| 13:47 | <wanderview> | hmm |
| 13:48 | <wanderview> | JakeA: ok, but that is pretty much the same as having initialClientId and reservedClientId |
| 13:48 | <wanderview> | JakeA: what do you think about removing the message queuing on reserved? |
| 13:49 | <JakeA> | wanderview: I think I'm missing the problem. If I want to send a message to the resulting client, resultingClientId is the place I go to do that. The queuing helps here, no? |
| 13:50 | <wanderview> | JakeA: but if its not reserved, then the message might fire in the window before the message event handler has been setup by the final loading document |
| 13:51 | <wanderview> | so the message will work for reserved... but may or may not work for initial |
| 13:51 | <wanderview> | making reserved not queue would avoid this since people wouldn't expect it to work |
| 13:52 | <JakeA> | wanderview: I thought we buffered messages until something like dom-ready, or does that stop working in the replaced case? |
| 13:52 | <wanderview> | JakeA: I kind of feel like instead of queuing messages we should provide some way to listen for the Client execution ready state change |
| 13:52 | <wanderview> | JakeA: I'm not sure how existing message buffering works with initial about:blank |
| 13:53 | <JakeA> | wanderview: won't we have the same problem with a client-ready event? If it's initial about:blank, the client is ready |
| 13:53 | <JakeA> | Whereas we want to know "the new document has loaded" |
| 13:53 | <wanderview> | JakeA: you can check the Client.url |
| 13:54 | <JakeA> | wanderview: So we'd need to know when the client url was the new url, and when dom-ready |
| 13:55 | <wanderview> | JakeA: I guess I was assuming we wanted to allow sites to dynamically built frames and message them... which would mean we need to be able to message the client while it has the about:blank document |
| 13:55 | <wanderview> | JakeA: well, you can pretty much do `client.url !== 'about:blank'` |
| 13:55 | <JakeA> | wanderview: but you can't do "wait until client.url == 'foo.html'" |
| 13:56 | <wanderview> | JakeA: no.. but if we had a "wait for execution ready" thing you could do that then check the URL |
| 13:56 | <JakeA> | wanderview: but what if the url is wrong? Wait 100ms and try again? |
| 13:56 | <wanderview> | JakeA: maybe need to expose .initial as a boolean getter... and then have "wait until execution ready and not initial" |
| 13:57 | <JakeA> | hmm |
| 13:57 | <wanderview> | JakeA: there is probably something that handles this stuff in the main window case without Clients API |
| 13:57 | <wanderview> | script blockers or something |
| 13:57 | <JakeA> | wanderview: given Firefox's current behaviour, is this a problem…? |
| 13:57 | <wanderview> | JakeA: I would ask bz or smaug, but they are probably traveling today |
| 13:57 | <JakeA> | wanderview: replacement only happens if the page doesn't load |
| 13:58 | <JakeA> | as in the initial page |
| 13:58 | <smaug> | wanderview: I'm not. I must avoid trumpland |
| 13:58 | <wanderview> | smaug: that is wise |
| 13:58 | <smaug> | ...for my mental health ;) |
| 13:58 | <JakeA> | :D |
| 13:58 | <wanderview> | smaug: I saw at least on person was stopped from getting on a plane last night |
| 13:59 | <wanderview> | one person |
| 13:59 | <botie> | one person is working very much but is earning very less |
| 13:59 | <JakeA> | I'm going to build a quick test for this postMessage stuff |
| 13:59 | <wanderview> | JakeA: you mean without Clients API in the mix? |
| 13:59 | <JakeA> | yeah |
| 13:59 | <wanderview> | ok |
| 14:00 | <JakeA> | in theory the clients postMessage stuff uses the same buffering |
| 14:00 | <JakeA> | or, it could do |
| 14:00 | <wanderview> | JakeA: well, not in my current code :-) |
| 14:00 | <JakeA> | :D |
| 14:01 | <wanderview> | JakeA: my WPT test right now specifically tries to postMessage() an initial about:blank while delaying the final document network load |
| 14:01 | <wanderview> | and I made that work |
| 14:01 | <JakeA> | that's pretty much the test I was about to write |
| 14:01 | <JakeA> | hah |
| 14:01 | <JakeA> | Well, if that works, we're fine then, right? |
| 14:01 | <wanderview> | JakeA: but... the question is should it work |
| 14:02 | <wanderview> | JakeA: I made it work in my Clients API re-write... but should it work? |
| 14:02 | <JakeA> | wanderview: I think so. Buffing like window.postMessage seems good |
| 14:02 | <wanderview> | smaug: is there anything that prevents a page from adding a message handler to an initial about:blank and receiving postMessage events before the final document loads? |
| 14:03 | <smaug> | no |
| 14:03 | <wanderview> | JakeA: I don't think we're on the same page here... my test is designed to show no buffering |
| 14:03 | <smaug> | message events are just events, so if there is a listener for such, it should get called |
| 14:03 | <wanderview> | smaug: we don't buffer postMessage() until a particular ready state or something? |
| 14:04 | <wanderview> | JakeA: see the "ping" cases in here: https://github.com/w3c/web-platform-tests/pull/6304/files |
| 14:04 | <smaug> | why would we... |
| 14:04 | <wanderview> | smaug: uh... because JakeA thought we might? :-) |
| 14:04 | <smaug> | such buffering might take forever |
| 14:04 | <wanderview> | smaug: I mean... the web does all kind of things that I can't explain |
| 14:04 | <JakeA> | I thought we did this with regular messages |
| 14:05 | <JakeA> | Hence https://html.spec.whatwg.org/multipage/web-messaging.html#dom-messageport-start |
| 14:06 | <smaug> | window.postMessage is different |
| 14:06 | <smaug> | older and simpler, I'd say |
| 14:06 | <JakeA> | client.postMessage is modelled to be similar |
| 14:06 | <smaug> | oh, hmm, you were talking about service worker stuff? |
| 14:06 | <smaug> | then no idea |
| 14:07 | smaug | tries to stay as far as possible from SW ;) |
| 14:07 | <wanderview> | smaug: well, I guess I assumed the various postMessage() things would be more aligned |
| 14:07 | <JakeA> | Gonne test window.postMessage & initial documents… |
| 14:07 | <wanderview> | JakeA: when is the MessagePort enabled if start() is not called? |
| 14:07 | <JakeA> | wanderview: it's like dom ready or something |
| 14:08 | <JakeA> | Or when there's an assignment to window.onmessage |
| 14:08 | <JakeA> | It's kinda weird |
| 14:08 | <wanderview> | smaug: do windows with initial about:blank documents get the DOM ready event? |
| 14:08 | <smaug> | we just dispatch the runnable in gecko and then Run() dispatches message event sync |
| 14:09 | <smaug> | wanderview: that I don't recall |
| 14:09 | <smaug> | readystatechange |
| 14:09 | <smaug> | I assume no |
| 14:09 | <smaug> | since they are ready from the beginning |
| 14:09 | <wanderview> | oh, they start ready from the beginning? |
| 14:10 | <wanderview> | JakeA: wouldn't that imply the MessagePort should be enabled? ^^^ |
| 14:10 | <JakeA> | Let's find out!! :D |
| 14:10 | <JakeA> | (writing a test) |
| 14:10 | <wanderview> | ok |
| 14:11 | wanderview | should probably start packing soon... |
| 14:16 | <JakeA> | wanderview: bleh, yeah, the message gets delivered before the page loads https://clear-princess.glitch.me/ |
| 14:18 | <wanderview> | JakeA: how can you tell? |
| 14:18 | <wanderview> | there is no message handler? |
| 14:18 | <wanderview> | oh, I see |
| 14:18 | <wanderview> | your slow-ass-page has the handler |
| 14:19 | <wanderview> | JakeA: how do you do the slow load in glitch? |
| 14:20 | <JakeA> | wanderview: can you see https://glitch.com/edit/#!/clear-princess?path=server.js:17:23? |
| 14:20 | <wanderview> | JakeA: oh, cool... didn't realize it had a server.js |
| 14:20 | <wanderview> | nice |
| 14:20 | <JakeA> | <3 glitch |
| 14:26 | <wanderview> | JakeA: do you think edge will have to implement URLSearchParams when they ship service workers? I bet a fair number of service workers use URLSearchParams |
| 14:41 | <JakeA> | wanderview: I left a note at https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/16856668-support-the-searchparams-property-of-url-objects. It feels like a smallish thing to implement right? I know there are complications with windowProxy.location |
| 14:41 | <wanderview> | thanks |
| 14:42 | <JakeA> | wanderview: I'm writing up the buffering issue in that thread btw |
| 14:42 | <JakeA> | the github one I mean |
| 14:42 | <wanderview> | JakeA: thanks... sorry, I was just throwing down my thoughts since I have to go get ready for travel shortly |
| 14:43 | <JakeA> | not at all, thanks for throwing the rest of the details down! |
| 15:03 | <TabAtkins> | smaug: Symbols are the GENSYM of JS - they let you add properties to objects that are *guaranteed* to not collide with anything else. |
| 15:04 | <TabAtkins> | In particular, this means you can write mixins that are guaranteed safe. You can extend built-in prototypes without all the problems that causes today. Etc. |
| 16:12 | <JakeA> | I can't find where the HTML spec starts the window.onmessage queue automatically. I thought it was after DOMContentLoaded |
| 16:13 | <JakeA> | I know it starts if you assign to onmessage, but not if you use addEventListener('message', …) |
| 19:59 | <ajeffrey_> | a question that came up in conversation with cbrewster wrt https://github.com/w3c/web-platform-tests/blob/master/html/semantics/embedded-content/the-iframe-element/iframe-append-to-child-document.html |
| 20:00 | <ajeffrey_> | the relevant bit of spec is https://dom.spec.whatwg.org/#concept-node-pre-insert |
| 20:00 | <ajeffrey_> | it looks like this passes the pre-insertion validity check https://dom.spec.whatwg.org/#concept-node-ensure-pre-insertion-validity |
| 20:02 | <ajeffrey_> | because childWindow.document is not a descendant of iframe. |
| 20:03 | <ajeffrey_> | AFAICT the spec allows a cycle in the DOM + browsing context hierarchies, but I must be missing something :/ |
| 20:04 | <ajeffrey_> | Domenic: any ideas ^ |
| 20:11 | <Domenic> | I don't remember any attempts to disallow cycles |
| 20:11 | <Domenic> | There's some part of the spec that deals with iframe nesting level I think that tries to prevent infinite loading |
| 20:14 | <TabAtkins> | Yeah, cycles are definitely allowed and work right now, they just get broken at some point. |
| 20:46 | <jugglinmike> | Domenic: Is it possible to specify, "Wait for the queue's next dequeue operation" ? |
| 20:47 | <jugglinmike> | I'm trying to use a queue to schedule request handling in WebDriver |
| 20:47 | <jugglinmike> | so my question is just one possible implementation |
| 20:48 | <jugglinmike> | although even that is probably too prescriptive |
| 20:48 | <jugglinmike> | Could I do something like, 1) Enqueue `request` in `pending requests`, 2) Wait for `request` to be the first element of `pending requests` |
| 20:50 | <jugglinmike> | I know this is blocking, but I think that's appropriate for a connection-oriented/request-initiated algorithm |
| 20:54 | <virmaha> | Hello. If a website has 50mb approx size video, how can the browser play it almost instantly? Whereas if i fetch the same file via XHR, the download takes approx 2.5 mins after which I can start playing it? |
| 21:10 | <TabAtkins> | The browser is streaming it - playing what it has while it downloads the rest - while XHRing the whole file doesn't finish until the whole file is downloaded. |
| 21:11 | <TabAtkins> | But if you use fetch(), you can stream the result straight into a <video> element. There are some tutorials out there with examples of this. |
| 22:36 | <virmaha> | TabAtkins: I see. However, I can't find fetch + video tutorials. All I could find is https://jakearchibald.com/2016/streams-ftw/ |
| 23:15 | <ajeffrey_> | Domenic: the pre-insertion check is indented to stop cycles in the DOM, |
| 23:15 | <ajeffrey_> | but it looks like there's nothing to stop cycles in the DOM+bc tree. |
| 23:21 | <ajeffrey_> | That is, can we get into a situation where A is a descendent of B, but B's browsing context is a child of A's? |
| 23:22 | <ajeffrey_> | bz: thoughts ^ |
| 23:47 | <annevk> | ajeffrey_: don't think so since stuff is tied to documents |
| 23:47 | <annevk> | ajeffrey_: bz doesn't hang out here unfortunately |
| 23:50 | <ajeffrey_> | annevk: so what stops it? I can see how DOM is acyclic, but not what in the spec stops examples like https://github.com/w3c/web-platform-tests/blob/master/html/semantics/embedded-content/the-iframe-element/iframe-append-to-child-document.html from forming cycles in DOM+bc. |
| 23:50 | <annevk> | ajeffrey_: https://dom.spec.whatwg.org/#concept-node-adopt I'd think |
| 23:53 | <ajeffrey_> | annevk: I don't see how that stops it, because "node’s shadow-including inclusive descendants" is just the DOM hierarchy, not anything to do with bcs. |
| 23:56 | <annevk> | ajeffrey_: when you append an iframe to its own BC, the iframe holding the BC gets removed and no new BC gets created as there's no top-level BC |
| 23:56 | <annevk> | ajeffrey_: I might be missing something though |