| 02:54 | <caitp> | so, some colleagues were talking about some security issues they were working on for stands implementation, and one was not convinced there was any need to do things differently from plain user space js |
| 02:54 | <caitp> | i tried to explain the threat model of leaking info synchronously, but admittedly, it's hard to come up with something compelling |
| 02:55 | <MikeSmith> | caitp: what is "stands" |
| 02:55 | <caitp> | streams |
| 02:55 | <caitp> | Swype-o |
| 02:58 | <MikeSmith> | ah ok |
| 02:59 | <MikeSmith> | I wasn't aware there's what new security risks Streams exposes |
| 03:00 | MikeSmith | looks at the spec |
| 03:00 | <caitp> | in this case they're talking about [[private field]] vs normal fields, afaik |
| 03:00 | <caitp> | properties* |
| 03:01 | <MikeSmith> | oh |
| 03:02 | <MikeSmith> | I don't remember reading discussion of that yet |
| 03:03 | <MikeSmith> | I mean in the github issue trackers discussions for Streams |
| 03:03 | <MikeSmith> | but maybe I need to read more carefully |
| 03:04 | <caitp> | it was either about implementation in blink or WebKit, probably blink because it sounded like they were using the private symbols thing there |
| 03:04 | <caitp> | so not spec specific necessarily |
| 03:04 | <MikeSmith> | ok |
| 03:04 | <MikeSmith> | incidentally I realize now that it seems like Streams discussion has slowed down a lot recently |
| 03:05 | <MikeSmith> | I used to get a lot of issue notifications for it but not much at all lately |
| 03:05 | <MikeSmith> | ah OK |
| 03:06 | <MikeSmith> | anyway at that level it seems like there are all kinds of gotchas when implementing something like this |
| 03:06 | <MikeSmith> | I mean in C++ |
| 03:07 | <caitp> | there is definitely a potential issue if user space gets control of non user space stuff, but i mean more in general about cross origin communications channels in DOM |
| 03:08 | <caitp> | seems like it could be useful for notifying an attacker of some kind of side channel, maybe |
| 03:08 | <MikeSmith> | oh |
| 03:09 | <MikeSmith> | I see now |
| 03:10 | <MikeSmith> | caitp: btw you working on browser-engine code these days? |
| 03:11 | <MikeSmith> | still contributing to Angular? |
| 03:11 | <caitp> | v8/webkit/blink, from most frequently to least frequently |
| 03:12 | <MikeSmith> | ah |
| 03:12 | <MikeSmith> | didn't know |
| 03:13 | MikeSmith | peruses some commit logs |
| 03:14 | <MikeSmith> | ara |
| 03:14 | <MikeSmith> | caitp: you working at Igalia? |
| 03:15 | <caitp> | yeeah, joined this summer/fall |
| 03:16 | <MikeSmith> | very cool |
| 03:16 | <MikeSmith> | massive respect to them |
| 03:17 | <MikeSmith> | seems like a very exceptional group of people |
| 03:17 | <caitp> | i think at least some of them hang out in here from time to time :p |
| 03:17 | <MikeSmith> | didn't know that |
| 03:18 | <MikeSmith> | I guess there's probably a few more people working there now than I realize |
| 03:18 | <MikeSmith> | I don't actually personally know anybody else who works there so well |
| 03:18 | <MikeSmith> | well I know Joanie some |
| 03:19 | <MikeSmith> | Joanmarie |
| 03:19 | <MikeSmith> | super cool |
| 03:19 | <caitp> | yeah, I thought spec editors would probably know her |
| 03:20 | <MikeSmith> | yeah, I'm extremely glad she's able to spend time contribuing to spec discussions, especially for accessibility stuff |
| 03:20 | <MikeSmith> | I think she's a major asset to the accessibility effort |
| 03:20 | <MikeSmith> | and voice of reason, etc. |
| 08:29 | <MikeSmith> | zcorpan: will review the build PR today |
| 08:29 | <zcorpan> | MikeSmith: ok thx |
| 08:30 | <MikeSmith> | (wasn't ignoring it, but just been working on trying to get a new validator release out) |
| 08:31 | <MikeSmith> | zcorpan: btw I finally changed the validator behavior to not report errors for ampersand cases that the spec says are not errors |
| 08:31 | <zcorpan> | (no worries) |
| 08:33 | <zcorpan> | MikeSmith: oh, cool. didn't you want the rules to be simpler there? or is the current spec OK? |
| 08:38 | <MikeSmith> | zcorpan: current spec is OK by me |
| 08:39 | <MikeSmith> | what I implemented in the parser conforms to the current spec, as far as I can remember |
| 08:39 | <zcorpan> | ok |
| 08:39 | <MikeSmith> | I'm a little fuzzy on it because I wrote the patch probably a year ago |
| 08:41 | <MikeSmith> | and to be the change hasn't been merged into the parser trunk; I'm resorting to checking it into a branch and having the validator use a build from that branch |
| 08:41 | <MikeSmith> | *and to be clear, |
| 09:03 | <zcorpan> | ok |
| 09:07 | <howdoi> | What does the service worker has acess to? |
| 09:07 | <howdoi> | I can't access DOM for sure, nor XHR |
| 09:14 | <annevk> | howdoi: you can use fetch() |
| 09:14 | <annevk> | howdoi: it should have most APIs that are exposed in workers, minus a few |
| 09:18 | <howdoi> | annevk: is there any list of which it can access and which it can't ? |
| 09:18 | <howdoi> | annevk: I am reading http://www.w3.org/TR/service-workers/ |
| 09:18 | <annevk> | howdoi: don't really know if anyone keeps a list |
| 09:19 | <annevk> | howdoi: read https://slightlyoff.github.io/ServiceWorker/spec/service_worker/ instead |
| 09:19 | <annevk> | howdoi: TR/ drafts are almost always the wrong thing to be reading |
| 09:19 | <howdoi> | Working Draft would be talking about it in bits and pieces |
| 09:20 | <annevk> | howdoi: I'm not sure what you mean, but the SW specification would not really talk about what APIs are available from ServiceWorkerGlobalScope, that's mostly up to other specifications |
| 09:32 | <howdoi> | annevk: thanks, I shall re-read it |
| 09:38 | <yoav> | annevk: friendly ping re https://github.com/whatwg/dom/pull/123 :) |
| 09:56 | <annevk> | Thanks, so many GitHub things to look at... Halved the list so far. |
| 09:57 | <annevk> | yoav: are you using an older version of bikeshed? |
| 09:57 | <yoav> | maybe... |
| 09:57 | <yoav> | I'll update and see if it changes things |
| 09:57 | <annevk> | yoav: it seems your generated dom.html changes the formatting of a bunch of things |
| 09:58 | <annevk> | yoav: I guess I can merge and overwrite that locally |
| 09:59 | <yoav> | I'm trying to update and see what it does, but feel free to merge and overwrite if you prefer |
| 10:02 | <annevk> | yoav: it seems that might be the problem; I merged this one, I guess now you've updated it'll be fine for the patch that fixes where supported tokens lives |
| 10:03 | <yoav> | yeah, the update was the issue :) |
| 10:52 | <nox> | annevk: No need to thank me, I introduced that damn typo. :) |
| 10:52 | <annevk> | heh |
| 10:52 | <annevk> | Well, I reviewed that change... |
| 10:53 | <nox> | annevk: Hah, true. :) |
| 12:29 | <howdoi> | annevk: jsfeatures.in is a progressive webapp, but the add to home screen banner is not getting triggered even after the bypass flag is enabled, any idea? |
| 13:15 | <annevk> | howdoi: nope |
| 13:21 | <smaug____> | hmm, I think I'm still missing webapps mailing list emails |
| 13:22 | <Domenic> | annevk: is https://github.com/whatwg/html/pull/373 ready to go or still reviewing? |
| 13:22 | <smaug____> | MikeSmith: is there some way to know who all are subscribed to webapps mailing list? |
| 13:23 | <smaug____> | I wonder if most of the people were kicked out there last week |
| 13:24 | <annevk> | Domenic: I think it requires globalThis to land on the other side, no? |
| 13:24 | <Domenic> | annevk: oh, that happened already, that's when I removed the "do not merge" label :) |
| 13:25 | <Domenic> | execution context tracking (for the script execution PR) is still in progress, but globalThis and InitializeHostDefinedRealm are now in ES |
| 13:25 | <annevk> | Domenic: hmm, the ECMAScript PR still has globalThis as an outstanding commit |
| 13:26 | <annevk> | Domenic: https://github.com/tc39/ecma262/commit/9474c58c6baf54e8b5347a182c2fa6ee10dab071 but I guess maybe that PR needs rebasing? |
| 13:27 | <Domenic> | annevk: the "master es2016-draft-20151210 " in the header of the commit means it's been merged into master and released in a tagged snapshot |
| 13:28 | <Domenic> | Ah it's that GitHub UI bug |
| 13:28 | <annevk> | Domenic: so I think it's good to merge then, ideally heycam also reviews this but we can ask him to come in after the fact |
| 13:28 | <Domenic> | He merged 3/4 commits in the PR, but GitHub doesn't update the PR to show that |
| 13:29 | <Domenic> | \o/ |
| 13:29 | <Domenic> | Yeah IDL needs more updates... |
| 13:29 | <Domenic> | IDL doesn't even talk about script settings objects, it talks about "stack of scripts"? |
| 13:29 | <Domenic> | This experience has convinced me to move IDL updates up on the priority stack, although they are still below cancelable promises which are below this script/module work. |
| 13:30 | <annevk> | I think I convinced heycam last week to do most of my outstanding requests regarding internal slots, more formalized algorithms, this, current realm, etc. but I'm not sure what timeline we're looking at |
| 13:31 | <annevk> | Domenic: so will you merge 373 yourself? |
| 13:31 | <Domenic> | annevk: yeah I will, when I get to work in a couple hours. |
| 13:31 | <annevk> | such great refactoring |
| 13:32 | <Domenic> | My biggest requests for IDL are an update for latest ES, and a merger of the two type sections/getting rid of the seperate "ES binding" concept. |
| 13:32 | <smaug____> | ahaa, bug in session history algo. "8. If the specified entry is not an entry with persisted user state, but its URL has a fragment identifier, scroll to the fragment identifier." should not happen when coming from bfcache |
| 13:32 | <annevk> | smaug____: I guess that wasn't considered since only Firefox has a bfcache :/ |
| 13:33 | <Domenic> | why is bfcache allowed in the standard? Can't it be a nonstandard Firefox extension if only one browser implements it and it affects interop in these kind of ways? |
| 13:33 | <smaug____> | annevk: webkit has it too |
| 13:33 | <Domenic> | hmmm |
| 13:34 | <annevk> | Domenic: so apparently WebKit has it too, but there's events too and I think someone told me a lot of the same issues come up with preload |
| 13:34 | <Domenic> | yeah this seems like the kind of interop situation we try to fix, not codify into the standard as "do either one, it's fine" |
| 13:34 | <smaug____> | hmm, perhaps that step 8 is fine if "entry with persisted user state" is interpreted certain way |
| 13:41 | <annevk> | Domenic: so I think Chrome is not convinced about the complexity of this feature and believes that typically the network is fast enough so that reloading is fine |
| 13:41 | <annevk> | Domenic: whereas other browsers want to retain some representation |
| 13:41 | <howdoi> | await is boring with try-catch block |
| 13:42 | <annevk> | Domenic: also, this being history and that fundamentally being tied to UI makes it hard to see a fully interoperable future, but perhaps we can get closer in some aspects |
| 13:54 | <annevk> | Domenic: so should https://bugs.ecmascript.org/show_bug.cgi?id=1898 be marked fixed? |
| 13:54 | <annevk> | Perhaps better to ask that in jslang |
| 14:00 | <Ms2ger> | Domenic, annevk: is https://github.com/domenic/window-proxy-spec still worth looking at? |
| 14:01 | <annevk> | Ms2ger: for same-origin only |
| 14:01 | <Ms2ger> | Right |
| 14:01 | <annevk> | Ms2ger: I need to find time to study the discussion from last week and write up something more coherent, but thus far I'm mostly catching up |
| 14:02 | <Ms2ger> | Ok |
| 14:02 | <annevk> | Ms2ger: and apparently I'm somewhat legally obliged to take more holiday for the remainder of the year starting Friday so... |
| 14:02 | Ms2ger | ponders trying to make nox write it up |
| 14:03 | <nox> | I would like some WebIDL stuff to actually support WindowProxy. |
| 14:03 | <annevk> | Heh, it's an interesting challenge for sure |
| 14:03 | <nox> | Because the current WindowProxy stuff in HTML is laughable. |
| 14:03 | <annevk> | nox: what would IDL provide? |
| 14:04 | <annevk> | nox: as I understand it all we need is internal methods which IDL doesn't really help with in any meaningful way |
| 14:04 | <nox> | No idea, but it seems insane to me that we have WindowProxy in the middle of nowhere, with a very vague definition, etc etc. |
| 14:04 | <Ms2ger> | annevk is working on the "vague" part, at least |
| 14:04 | <nox> | annevk: Well, ES6 has proxies, WebIDL doesn't, what about "proxy WindowProxy { /* what goes there to be defined */ }" |
| 14:05 | <annevk> | What Domenic has written up coupled up with more internal methods overrides and origin checks is roughly what we'll end up with I suspect |
| 14:05 | <annevk> | nox: if your IDL "interface" (to be renamed "class" one day) defines getter/setter stuff you'll get a proxy |
| 14:05 | <nox> | annevk: Still sounds better than prose with a interface not defined anywhere in actual IDL. |
| 14:06 | <MikeSmith> | smaug____: there's no public way to view the set of subscribers to a list afaik. I can see it myself though |
| 14:06 | <Domenic> | I think you would need a pretty new language if you wanted to write up WindowProxy in IDL |
| 14:06 | <nox> | Domenic: Ah? |
| 14:07 | <annevk> | MikeSmith: that API is available to Members too |
| 14:07 | <Domenic> | nox: it doesn't correspond to basically any concepts in IDL as it exists today. Extending IDL to give enough power would essentially create a micro-language inside IDL which is entirely composed of features to make WindowProxy work. |
| 14:07 | <nox> | I see. |
| 14:08 | <annevk> | MikeSmith: w3.org 404s have mixed content |
| 14:09 | <MikeSmith> | oh, will try to get those 404 pages fixed |
| 14:09 | <annevk> | The only thing WindowProxy needs from IDL is acknowledgment that it exists and can be used in IDL interfaces |
| 14:09 | <nox> | annevk: And WebIDL doesn't provide that, right? |
| 14:10 | <nox> | annevk, Domenic: What if we had just "proxy WindowProxy;"? |
| 14:10 | <MikeSmith> | annevk: actually those will be fixed when they deploy upgrade-insecure-requests, right? |
| 14:10 | <Domenic> | sure or "typename WindowProxy" |
| 14:10 | <Domenic> | we need the same thing for ReadableStream |
| 14:10 | <MikeSmith> | win 35 |
| 14:11 | <nox> | Gecko does "interface WindowProxy;" |
| 14:11 | <annevk> | MikeSmith: I guess |
| 14:11 | <nox> | (IIRC). |
| 14:11 | <Domenic> | yeah that seems reasonable too |
| 14:11 | <annevk> | nox: it's the same problem Uint8Array et al have |
| 14:11 | <annevk> | nox: but IDL mentions those already in various places to make things work |
| 14:11 | <nox> | annevk, heycam|away: Btw, have you thought a bit more about [[HasInstance]] for NodeFilter? |
| 14:12 | <annevk> | perhaps if Domenic's grand flattening plan is executed that problem disappears altogether |
| 14:12 | <annevk> | nox: I haven't, was happy for you all to sort it out |
| 14:12 | <nox> | Yeah, I was happy this meeting happened too. |
| 14:13 | <nox> | The code I had to read was extremely confusing, glad that bz confirmed it was actually mostly dead code. |
| 14:13 | <MikeSmith> | smaug____: as annevk reminds me there's member-only access to subscriber lists, so I'll find a URL you can try |
| 14:13 | <Ms2ger> | > Worker initialization was refactored extensively, to avoid creating WorkerGlobalScope objects before the corresponding realm was created. (The existing setup had the problem where it was creating a WorkerGlobalScope, derived from Object, in a thread that didn't even exist yet.) |
| 14:13 | <Ms2ger> | Woo |
| 14:14 | <annevk> | MikeSmith: smaug____: https://www.w3.org/Member/Mail/AuditForm |
| 14:14 | <nox> | annevk: Though, |
| 14:14 | <MikeSmith> | thanks annevk |
| 14:14 | <nox> | I just realised we didn't have any meeting about whichever step in document.write() that confuses me. :( |
| 14:15 | <annevk> | MikeSmith: smaug____: https://www.w3.org/services/list-audit/query?queryList=public-webapps in particular |
| 14:15 | <Ms2ger> | Oh, did we get a bug filed about the dead code? |
| 14:15 | <nox> | Ms2ger: No idea. |
| 14:15 | <nox> | Ms2ger: Ask bz. |
| 14:15 | <Ms2ger> | I don't think so |
| 14:15 | <Ms2ger> | bz is on vacation to NZ |
| 14:15 | <nox> | Oh right. |
| 14:15 | <nox> | So probably not. |
| 14:15 | <annevk> | MikeSmith: smaug____: the main problem though is that for lists that are partially DB-backed you'll also need to check who is part of the group since those will also have gotten the email and are not listed on that page, aiui |
| 14:16 | <Ms2ger> | nox, can you write down what exactly is dead code, so I can file? |
| 14:16 | <annevk> | nox: filing GitHub issues is a decent substitute for meetings though |
| 14:16 | <nox> | annevk: True. |
| 14:16 | <nox> | Ms2ger: Will do that tonight. |
| 14:17 | <nox> | I'm still supposed to work on insane PHP code, mind you. :P |
| 14:17 | <Ms2ger> | Send me an email? |
| 14:18 | <nox> | Ms2ger: Will do. |
| 14:18 | <Ms2ger> | Thanks |
| 15:00 | <nox> | annevk: Maybe "external interface Foo;" would be better? Bikeshedding though. |
| 15:02 | <annevk> | nox: it's not clear to me that we need to use IDL syntax for them |
| 15:02 | <annevk> | nox: what we need is something that makes it clear they can be used in IDL using verbiage X coupled perhaps with some restrictions where they can be used (e.g., using WindowProxy in worker APIs would be bad) |
| 15:03 | <annevk> | nox: and we need to define what it means to create new instances of them from within IDL algorithms |
| 15:03 | <annevk> | nox: there might be some other things |
| 15:04 | <nox> | annevk: I see. |
| 15:04 | <annevk> | nox: but "bikeshed syntax" doesn't really solve any of those per se |
| 15:04 | <nox> | Definitely. |
| 15:59 | <smaug____> | MikeSmith: ok, thanks. Looks like some essential people are now missing from the mailing list |
| 15:59 | <smaug____> | and Apple isn't currently a member of the wg |
| 16:03 | <annevk> | smaug____: per https://www.w3.org/services/list-audit/query?queryList=public-webapps most Apple employees do get emails though |
| 16:04 | <smaug____> | annevk: well, not rniwa for example |
| 16:08 | <annevk> | smaug____: I see, sigh |
| 16:13 | <nox> | annevk: I think proxy … { … } would be the way to go. We could then say that interfaces with special operations get an implicit proxy on which these operations are defined, and we could make something like [Proxy=WindowProxy] on Window or any interface which need a more exotic proxy thing. |
| 16:13 | <annevk> | nox: what problem are you trying to solve? |
| 16:14 | <nox> | None particularly, I just hate how WindowProxy is specified and would like it to be more WebIDL-friendly. |
| 16:16 | <Domenic> | I really don't see a need to put anything in Web IDL for this |
| 16:21 | <annevk> | Right, inventing IDL syntax does not solve problems so I'm also at a loss |
| 16:31 | <nox> | Domenic, annevk: Disregard me then. :) |
| 16:36 | <gsnedders> | http://stackoverflow.com/questions/9675750/if-ie-comments-showing-up-in-ie9 is weird, seems like parsing of conditional comments in old IE can end up with valid comments being treated as text o_O |
| 16:39 | <nox> | annevk: Should DOM be updated to use FrozenArray? |
| 16:39 | <annevk> | nox: where? |
| 16:41 | <nox> | Never mind I thought arrays were used in there somehow. |
| 16:51 | <Ms2ger> | Oh, add-topic is dead? |
| 16:56 | <annevk> | Ms2ger: what is add-topic? |
| 16:56 | <Ms2ger> | <annevk> No need to introduce new ADD-TOPIC or REMOVE-TOPIC syntax. It's no longer used. |
| 16:57 | <annevk> | Ms2ger: oh, see, with uppercase it's much clearer |
| 16:57 | <annevk> | Ms2ger: yeah, that died with the transition to GitHub |
| 17:05 | <Domenic> | what did it do? |
| 17:32 | <annevk> | Domenic: it was used for emailing folks when a topic they cared about ended up being changed |
| 17:32 | <annevk> | Domenic: we discussed it to some extent when migrating and it wasn't used enough to care |
| 18:24 | <annevk> | nikkibee: can I help with the CORS-preflight cache confusion? |
| 18:25 | <nikkibee> | annevk: yes, I'd appreciate that! |
| 18:25 | <nikkibee> | I'm not sure what it *accomplishes* |
| 18:25 | <nikkibee> | like I can see it's doing this stuff but it seems very circular to me |
| 18:25 | <nikkibee> | if there's no cache, then make the cache to compare against later? |
| 18:26 | <nikkibee> | what I'm thinking is the answer right now is how CORS-preflight Fetch can return a network error |
| 18:26 | <annevk> | nikkibee: if there's no cache entry, make this preflight fetch to populate the cache (and make sure the server knows about CORS at the same time) |
| 18:26 | <nikkibee> | is that so if something is in the cache, we can be sure it's good? and if it doesn't match the catch, we need to run validation on it again? |
| 18:26 | <annevk> | nikkibee: correct |
| 18:27 | <nikkibee> | ahh, I get it now! thanks |
| 18:27 | <nikkibee> | I mean, "we can be sure it's good" is pretty simple, but I'm sure I'll get a better idea of what validity means as I gain more experience with Fetch :) |
| 18:28 | <nikkibee> | would it be accurate to say it checks for CORS security? |
| 18:29 | <annevk> | nikkibee: it's basically a check to see the server understands CORS and is happy to handle cross-origin requests that go outside the traditional security model of the web |
| 18:29 | <nikkibee> | gotcha, thanks! |
| 18:30 | <annevk> | nikkibee: if you can think of places where some extra explanation would help that'd be welcome as issues / PR |
| 18:30 | <nikkibee> | annevk: I think more notes in general would be a good thing. whenever a step has a note it usually seems to be giving me the reason for the step |
| 18:31 | <nikkibee> | I don't always understand what the note itself means, but I often get that it's relating to something beyond the Fetch spec itself, and that I'd be doing something that'll be used later |
| 18:31 | <annevk> | nikkibee: notes are typically included based on PRs/issues or when I find something particularly complicated myself |
| 18:31 | <annevk> | I guess they might still be too abstract at times... |
| 18:31 | <nikkibee> | well my main thing is like |
| 18:32 | <nikkibee> | I've gone through all the steps, but it's not easy to understand the big picture |
| 18:32 | <nikkibee> | I don't know what the *point* of each different Fetch function is from the outset |
| 18:32 | <nikkibee> | like I kinda get that things enter in Fetch; go to Main Fetch to get sorted to Basic Fetch or HTTP Fetch; and HTTP Fetch covers a lot of different ground |
| 18:33 | <nikkibee> | but all the introductions are like "To perform an HTTP-network fetch using request with an optional credentials flag, run these steps:" and I don't know what the *goal* is |
| 18:34 | <annevk> | well the goal is representing response = fetch(request) |
| 18:34 | <annevk> | things are abstracted into their own algorithm if they are reused or when that is good for clarity |
| 18:34 | <nikkibee> | that makes sense |
| 18:35 | <nikkibee> | I hadn't thought about the reusing aspect, though I have noted what gets called where |
| 18:35 | <annevk> | we could have some more notes with a basic explanation I suppose, but a lot of the algorithms don't mean much by themselves |
| 18:36 | <annevk> | and we might change the arrangement I suppose if that becomes necessary at some point |
| 18:36 | <nikkibee> | fair enough |
| 18:36 | <annevk> | E.g., "main fetch" is a fairly recent addition we didn't need before |
| 18:36 | <nikkibee> | I think something could be done for the CORS-preflight cache on pointing out what I eventually concluded |
| 18:37 | <nikkibee> | huh, are the steps in main fetch new? or were they elsewhere? |
| 18:37 | <annevk> | nikkibee: they used to be in "fetch" |
| 18:38 | <annevk> | nikkibee: would that help at the top of CORS-preflight fetch though or in HTTP fetch step 4.1? |
| 18:38 | <nikkibee> | that sounds like a good change, if at least so each method is a bit shorter |
| 18:38 | <nikkibee> | annevk: both I think. like you would say different things in each place |
| 18:39 | <annevk> | nikkibee: we made it because we needed to reinvoke "fetch" from redirects, but wanted to keep some things unchanged |
| 18:39 | <nikkibee> | like in HTTP fetch step 4.1 it could be like "if something is in the cache, it's been validated. if it's not, we need to validate it" |
| 18:39 | <annevk> | nikkibee: so now redirects reinvoke "main fetch" and whatever is done in "fetch" is left alone |
| 18:39 | <nikkibee> | right |
| 18:40 | <annevk> | nikkibee: could you comment in the preflightResponse issue to that effect? I'll add some notes tomorrow |
| 18:41 | <nikkibee> | sure thing |
| 18:43 | <annevk> | philipj: https://www.chromestatus.com/metrics/feature/timeline/popularity/1061 looks excellent, but I guess we need to wait longer |
| 18:44 | <annevk> | philipj: btw, going directly to that URL in Firefox doesn't update the <select> correctly |
| 18:50 | <philipj> | annevk: what you're seeing is probably https://github.com/GoogleChrome/chromium-dashboard/issues/220 |
| 18:52 | <philipj> | annevk: and yes, that use counter will be in M49, with an "Estimated Week of Stable" Feb 29th, 2016 |
| 18:53 | <philipj> | it does look pretty promising compared to some other recent counters, though |
| 18:53 | <philipj> | annevk: if there's any hurry, a googler might be able to tell you numbers from the dev channel |
| 19:05 | <Domenic> | is importScripts() just sync xhr in disguise? |
| 19:16 | <Domenic> | Who wants to add a "never show this again" to the "too slow" checkbox. jeez. |
| 19:16 | <Domenic> | s/checkbox/popup/ |
| 19:16 | <Domenic> | although I guess if it uses cookies it's not going to work on my file:// URL copy |
| 19:18 | <annevk> | Domenic: importScripts() is sync, but only for workers |
| 19:19 | <Domenic> | yeah i guess we allow workers to jank themselves anyway |
| 19:40 | <wanderview> | Domenic: we also do some special things for importScripts() in service workers |
| 19:40 | <wanderview> | monkey patching: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#importscripts |
| 19:41 | <Domenic> | wanderview: yeah i saw junkees did a nice refactoring a while back to allow ServiceWorkerGlobalScope.importScripts to reuse most of the algorithm |
| 19:41 | <Domenic> | That's not monkeypatching :). What was there before was monkeypatching... "do importScripts but instead of step 7, do X, and after step 8, do Y." |
| 19:42 | <wanderview> | ok |
| 19:43 | <rits> | hello i am starting on this bug https://github.com/whatwg/html/issues/176, needed some starting points for it |
| 19:46 | <Domenic> | rits: do you need help with the tooling, or with the contents of the bug? If the latter, annevk is the person to ask. If he's not around in this channel right now you can try asking clarifying questions on the bug thread itself. |
| 19:48 | <rits> | Domenic: yeah, according to timezone he is not around now, i will discuss with him for the content part tomorrow, thanks |
| 20:01 | <smaug____> | majidvp: about scrollRestoration |
| 20:02 | <smaug____> | majidvp: the spec currently hints that history.scrollRestoration = 'manual'; somewhere in a script in head is enough to give manual handling everywhere |
| 20:02 | <smaug____> | but #hash handling in session history doesn't get that |
| 20:02 | <smaug____> | hmm, I should just file a bug about the example in the spec I guess |
| 20:02 | <smaug____> | or perhaps we want to change the spec |
| 20:05 | <Domenic> | speaking of which |
| 20:05 | <Domenic> | does majidvp or smaug____ want to make a PR for https://github.com/whatwg/html/issues/350#issuecomment-159753715 |
| 20:06 | smaug____ | should probably try to figure out how to write a pr for the spec |
| 20:07 | <smaug____> | but it is github |
| 20:07 | <smaug____> | which means hassle to me |
| 20:08 | <smaug____> | Domenic: so, which file should I modify? |
| 20:08 | <smaug____> | source? |
| 20:08 | <Domenic> | smaug____: yep. https://github.com/whatwg/html#pull-requests should give the info needed. |
| 20:13 | <majidvp> | smaug: I can make the PR for issue 350 if you don't have the repo setup. |
| 20:14 | <smaug____> | majidvp: thanks |
| 20:14 | <smaug____> | majidvp: any feedback to https://github.com/whatwg/html/issues/404 |
| 20:14 | <smaug____> | great issue number :) |
| 20:17 | <majidvp> | smaug____: As for the #hash, my read of the spec is that "history.scrollRestoration=manual" takes precedent over hash. In particular, step 8 says "If the specified entry is not an entry with persisted user state, but its URL has a fragment identifier, scroll to the fragment identifier." |
| 20:19 | <majidvp> | smaug____: In other words, if we have any scroll information for the entry (including scrollRestoration='manual') then we should not scroll to hash. |
| 20:19 | <smaug____> | majidvp: FYI, chrome does scrolls with #hash |
| 20:19 | <smaug____> | s/scroll/scroll/ |
| 20:19 | <smaug____> | so #hash takes precedence |
| 20:20 | <smaug____> | majidvp: also "entry with persisted user state" doesn't mean scrollRestoration state |
| 20:21 | <smaug____> | as far as I see |
| 20:21 | <smaug____> | since scrollRestoration is an explicitly defined state |
| 20:25 | <majidvp> | The Chrome behaviour is that it scrolls to hash on first load (where scrollRestoration = Auto) but it does not on any history traversal if the page has already set scrollRestoration=Manual. |
| 20:26 | <majidvp> | https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/fast/history/scroll-restoration/scroll-restoration-fragment-navigation-crossdoc.html&sq=package:chromium&type=cs |
| 20:29 | <majidvp> | smaug____: what do you think the right behaviour should be? The spec gives precedent on history scroll restoration over navigation to hash so I think scrollRestoration=Manual should also take precedent over hash. |
| 20:32 | <smaug____> | majidvp: the spec gives precedence to fragment navigation |
| 20:32 | <smaug____> | but I think that is wrong |
| 20:32 | <smaug____> | thouhg |
| 20:32 | <smaug____> | thouhg |
| 20:32 | <smaug____> | though :) |
| 20:32 | <smaug____> | what should happen to the hashchange event? |
| 20:33 | <smaug____> | it would still be dispatched, even without scrolling? |
| 20:34 | <smaug____> | majidvp: which behavior you want? |
| 20:39 | <smaug____> | I guess dispatching hashchange is fine even without scrolling |
| 20:39 | <smaug____> | is scrollRestoration is 'manual' |
| 20:39 | <smaug____> | s/is/if/ |
| 20:42 | <majidvp> | smaug____: yes, firing hashchange is independent of scrolling to fragment. It happens even if there is no fragment matching the hash. |
| 20:44 | <smaug____> | majidvp: you'll file a blink bug? |
| 20:44 | <smaug____> | or should I? |
| 20:44 | <Domenic> | I'm pretty excited about killing UTF16 in textencoder |
| 20:49 | <majidvp> | smaug____:I can file a bug. Do you have a repro? Is it on first load, or when traversing back to the page? |
| 20:50 | <smaug____> | majidvp: when traversing back at least |
| 20:50 | <smaug____> | I just manually tried something with http://mxr.mozilla.org/mozilla-central/source/dom/events/Event.cpp |
| 20:51 | <smaug____> | load that, set 'manual' |
| 20:51 | <smaug____> | scroll/click 199 on the left |
| 20:51 | <smaug____> | then load about:blank |
| 20:51 | <smaug____> | and go back |
| 20:51 | <smaug____> | the mode is still manual, but page is scrolled |
| 20:54 | <smaug____> | majidvp: note, there is also "update the session history with the new page" where steps 4-6 do fragment scrolling |
| 20:56 | <majidvp> | That sounds like a bug. I will file it. |
| 21:06 | <majidvp> | Hmmm, my first read suggests that "update the session history with the new page" is only invoked for new entries (i.e., history.scrollRestoration != Manual) which probably means it can be left as is. |
| 21:15 | <majidvp> | on closer examination, the algorithm allows UA to spin the event loop for sometime before trying to scroll to fragment in a loop. So it is potentially possible for script to run in mean time and update scroll restoration mode for the entry to Manual. I think, it is more appropriate to leave this as is, i.e., scroll to fragment for new pages is not impacted |
| 21:15 | <majidvp> | by scroll restoration mode. |
| 21:18 | <smaug____> | "traverse the history" in step 1 calls "navigate", which then calls 7.6.2 which does 'update the session history with the new page' |
| 21:18 | <smaug____> | but maybe I'm missing some step in 'navigate' where we'd return early |
| 21:42 | <majidvp> | I think you maybe right. I left a comment on the issue. |
| 22:40 | <Domenic> | Hmm Chrome regressed typeof document.all to "object" and it didn't break the internet https://code.google.com/p/chromium/issues/detail?id=567998 |
| 22:41 | <Domenic> | I mean it kind of broke some stuff but not completely |
| 23:09 | <miketaylr> | Domenic: oh man, i'd be afraid of how many dhtml menus are suddenly busted |
| 23:10 | <miketaylr> | (on sites that nobody visits, probably) |
| 23:49 | <gsnedders> | jgraham: critic appears to not have an up-to-date master for html5lib |
| 23:50 | <gsnedders> | jgraham: this is quite possibly why it hasn't been creating reviews |
| 23:53 | <jgraham> | gsnedders: It appears that you rewrote history on master |
| 23:53 | <jgraham> | Well I hope it was you |
| 23:57 | <gsnedders> | jgraham: I'm gonna look innocent. Though it seems not entirely implausible. |
| 23:58 | <jgraham> | Please tell me you didn't rewrite history to reformat a commit message |