| 00:27 | <KiChjang> | does anyone here have a good knowledge of chromium's development history? |
| 00:27 | <KiChjang> | i am particularly interested in chromium 28 |
| 00:29 | <KiChjang> | and want to know whether it primarily used WebKit for the DOM stuff, and only managed the IPC and process framework differently |
| 02:11 | wanderview | wonders if JakeA is still on PTO. |
| 02:15 | <wanderview> | falken: ping |
| 02:19 | <falken> | wanderview: pong |
| 02:20 | <wanderview> | falken: hi! I noticed an oddness in the WPT tests for client.navigate() and was wondering if chrome did the same here |
| 02:20 | <wanderview> | or if its a bug in firefox |
| 02:21 | <wanderview> | falken: it seems the test expects a cross-origin client.navigate() to reject... but I can't find where the spec says to do that: http://searchfox.org/mozilla-central/source/testing/web-platform/tests/service-workers/service-worker/resources/client-navigate-worker.js#46 |
| 02:21 | <falken> | wanderview: I can run Chrome on the test. Which tests should I try? |
| 02:21 | <wanderview> | falken: its client-navigate.https.html |
| 02:21 | <wanderview> | maybe you have an expected pass/fail for it already? |
| 02:21 | <wanderview> | I think the test might be wrong |
| 02:22 | <falken> | wanderview: We are skipping the test for various reasons |
| 02:22 | <falken> | https://bugs.chromium.org/p/chromium/issues/detail?id=658997#c13 |
| 02:23 | <falken> | Not too sure the conclusion of the comment but it looks like shimazu@ was also unsure about the rejection. |
| 02:24 | <falken> | Let me try to find the history of this test |
| 02:24 | <wanderview> | falken: looking at the spec: https://w3c.github.io/ServiceWorker/#client-navigate |
| 02:24 | <wanderview> | all I see is: "HandleNavigate: Navigate browsingContext to url with exceptions enabled. The source browsing context must be browsingContext." |
| 02:24 | <wanderview> | but I don't think that throws an exception for cross-origin url |
| 02:25 | <wanderview> | the navigate steps are a bit confusing to me, though |
| 02:26 | <wanderview> | and then later in step 10 the client.navigate() algorithm handles the cross-origin case by resolving null instead of a WindowClient object |
| 02:26 | <wanderview> | falken: I can write a small test site and see what chrome does... |
| 02:26 | <wanderview> | and I can fix the test if its broken |
| 02:27 | <falken> | Sure. I'm trying to see where the test came from. |
| 02:28 | <wanderview> | falken: then test came from here: https://bugzilla.mozilla.org/show_bug.cgi?id=1218148 |
| 02:28 | <falken> | Ah, thanks. |
| 02:28 | <wanderview> | I think its just a bug we introduced and codified in the test |
| 02:28 | <falken> | Our navigate() tests are here: https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/windowclient-navigate.html |
| 02:29 | <wanderview> | falken: ok... looks like chrome does what the spec says then: https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/windowclient-navigate.html?l=51 |
| 02:29 | <falken> | Agreed, we seem to expect the promise to resolve with undefined |
| 02:30 | <falken> | Sorry, null |
| 02:31 | <falken> | By the way, what's the easiest way to run the WPT tests against Firefox? Sometimes we have similar questions. |
| 02:31 | <falken> | Hopefully without needing to checkout/build Firefox. |
| 02:32 | <wanderview> | falken: thats a good question... I usually run it from a local build which is not convenient if your not working on it |
| 02:32 | <wanderview> | falken: I think there is a way to run WPT tests in a local web server and just point the browser at it though... maybe Domenic knows? |
| 02:32 | <Domenic> | You do ./serve inside a clone of WPT |
| 02:33 | <Domenic> | You may have to modify your /etc/hosts as per the WPT readme first depending on what tests you are running |
| 02:33 | <wanderview> | Domenic: do you have to clone git sub-repo's and stuff? |
| 02:33 | <Domenic> | hmm yeah I guess so |
| 02:33 | <wanderview> | ok |
| 02:33 | <Domenic> | https://github.com/w3c/web-platform-tests#running-the-tests |
| 02:33 | <wanderview> | falken: thanks for your help! saved me some time hunting things down |
| 02:33 | <falken> | np thanks |
| 02:34 | <kochi> | I can't access any w3.org sites. Are they offline? |
| 02:36 | <JakeA> | wanderview: I'm working today & tomorow |
| 02:37 | <wanderview> | JakeA: well, in this case you successfully delayed until falken answered my question :-) |
| 02:42 | <wanderview> | falken: here is the bug to fix client.navigate() and the test: https://bugzilla.mozilla.org/show_bug.cgi?id=1351935 |
| 02:44 | <domfarolino> | Domenic: do you think it is worth opening up a chromium issue for the removal of timeline/timelineEnd or is Paul saying they're comfortable getting rid of it enough? |
| 02:45 | <domfarolino> | reason I'm asking here and not the thread is because didn't feel it was worth firing off 6 unnecessary emails for |
| 02:48 | <botie> | i already had it that way, chatter29. |
| 02:50 | <wanderview> | JakeA: what is the count on number of people for the meeting next week? my impression is it will be quite large |
| 02:54 | <wanderview> | kochi: w3.org seems to load for me |
| 02:54 | <domfarolino> | is loading for me now too, wasn't earlier though for a bit |
| 03:23 | <JakeA> | wanderview: around 30! |
| 03:23 | <wanderview> | woah |
| 03:29 | <kochi> | ah, I can load w3.org now. was just flaky. |
| 03:30 | <Domenic> | domfarolino: I think it'd be good, you can cc paul there |
| 03:31 | <JakeA> | wanderview: I'm spending today and tomorrow figuring out an agenda. Will be interesting to see how much of the room is spectating and how much actively contributes. I'm going to try and keep it informal, but invite people to raise hands if they don't feel heard |
| 03:31 | <wanderview> | cool |
| 04:29 | <MikeSmith> | 30 people is a lot for this kind of meeting |
| 04:31 | <MikeSmith> | kochi: about w3.org services/sites there as some kind of hiccup earlier but it seems to have been rectified |
| 04:32 | <kochi> | MikeSmith: thanks, I can access them now. |
| 04:33 | <MikeSmith> | ok |
| 04:34 | <MikeSmith> | not sure what the problem was but maybe just MIT doing maintenance during “off” hours |
| 04:34 | <MikeSmith> | which aren’t “off” hours for us of course |
| 07:01 | <annevk> | Seems like there's almost no tests for ancestorOrigins (apart from some IDL stuff) and testharness.js relies on it, good times |
| 07:01 | <annevk> | I hope it doesn't rely on it in a way that makes changing its behavior problematic |
| 07:12 | <wanderview> | JakeA: so the changes that introduce FetchEvent.reservedClientID also introduce the possibility that FetchEvent.clientID is non-null for navigations |
| 07:13 | <wanderview> | JakeA: do you think we should keep forcing FetchEvent.clientID to be null until reservedClientID is implemented? |
| 07:13 | <wanderview> | my current work can actually start providing FetchEvent.clientID, but I'm not ready to expose reservedClientID yet... just wondering what would be best for devs |
| 07:15 | <JakeA> | wanderview: I think you're right, we should aim to keep clientId null until reservedClientId is implemented, then there's always a way to detect a potentially-client-making request |
| 07:16 | <JakeA> | *scratches head* does that make sense? |
| 07:16 | <wanderview> | JakeA: yea, thanks |
| 07:16 | <JakeA> | Thanks for all the issues on the client stuff btw, and sorry I haven't responded to many of them |
| 07:16 | <JakeA> | Hopefully we can chew through them all on Monday/Tuesday |
| 07:20 | Domenic | checks... it is spelled clientId, with a lowercase "d". Phew. |
| 07:27 | <tobie> | annevk: looking at the testharness.js PR you just filed, I think I wrote this this code and the related comment ( a *while* ago). |
| 07:28 | <annevk> | tobie: yeah, Safari only recently fixed this |
| 07:29 | <annevk> | testharness.js could really do with some triage |
| 07:29 | <annevk> | lots of PRs without a clear signal |
| 07:29 | <tobie> | annevk: testharness needs a test suite of its own for a start |
| 07:29 | <annevk> | That would be nice... |
| 07:41 | <tobie> | Domenic: latest PR changes look good. |
| 07:42 | <tobie> | Domenic: you backed out of the [TreatNullAsEmptyString] change in the PR, but we'll still need to get [TreatAsNull] rewritten as type extended attributed, no? |
| 07:43 | <tobie> | Domenic: I didn't have coffee this morning and it shows. :-/ |
| 07:44 | <tobie> | Domenic: What I meant is that we'll still need to rewrite specs that use [TreatAsNull] on an attribute to use it on the type instead, correct? |
| 07:45 | <tobie> | Domenic: if so, what was your reasoning in backing out of the [TreatNullAsEmptyString]? |
| 07:46 | <annevk> | tobie: note that Bikeshed also autolinks TreatNullAs: https://dom.spec.whatwg.org/#interface-domimplementation |
| 07:46 | <annevk> | (not TreatAsNull) |
| 07:47 | <tobie> | annevk: lol, looks like I'm not the only one mixing this up. :D |
| 07:48 | <annevk> | If we're going to simplify, I'd almost argue for [NullIsEmptyString], but... |
| 07:50 | <wanderview> | Domenic: but we have ServiceWorker.scriptURL... seems like .clientID would be consistent with that... |
| 07:50 | <wanderview> | we should probably just follow whatever XMLHttpRequest did... |
| 07:51 | <wanderview> | we can take a few hours next week to sort out the acronyms |
| 07:53 | <annevk> | wanderview: no, please be consistent with https://w3ctag.github.io/design-principles/#casing-rules |
| 07:55 | <tobie> | wanderview: see https://w3ctag.github.io/design-principles/#casing-rules |
| 07:55 | <tobie> | arg, annevk beat me to it. |
| 08:03 | <Domenic> | tobie: my reasoning was because separate PRs make sense as you said. |
| 08:03 | <Domenic> | Some specs might not need rewriting; mostly if they use optional they would |
| 08:04 | <Domenic> | wanderview: "id" is short for "identity" not "I Dentity" |
| 08:05 | wanderview | learns not to joke about acronyms in this channel. |
| 08:10 | <Domenic> | Well, I figured the XHR was a joke... but the first sentence I wasn't so sure :) |
| 08:23 | <tobie> | wanderview: did I mention I didn't have coffee this morning yet? |
| 08:25 | <tobie> | Domenic: I agree separate PRs generally make more sense, but then if this a lot of intersection between the rewriting both PRs imply for specs, it might have made sense to keep them together nonetheless. |
| 08:26 | <tobie> | Domenic: you seem to suggest that's not really the case, so we're good like this. |
| 08:26 | <annevk> | Domenic: what do you think about my first child rewording suggestion? |
| 08:26 | <annevk> | Domenic: I can create a PR |
| 08:27 | <Domenic> | annevk: meh, yeah, I guess I can sign off on PRs, but not a big deal IMO. Be sure to catch all three places the term is used. |
| 08:28 | <annevk> | Domenic: I read it the same as chaals did |
| 08:28 | <annevk> | I can mark it editorial so nobody is in the wrong :p |
| 08:29 | <Domenic> | :) |
| 08:33 | <wanderview> | tobie: np |
| 08:34 | <wanderview> | falken: has chrome implemented the byte-for-byte comparison of importScripts() yet? |
| 08:34 | <falken> | wanderview: I'm sorry, no we haven't. |
| 08:34 | <wanderview> | falken: ok, np... I'm just reviewing our WPT test for the feature and was curious if I could run it against chrome |
| 08:34 | <falken> | https://bugs.chromium.org/p/chromium/issues/detail?id=648295 |
| 10:38 | <annevk> | beverloo: https://github.com/w3c/web-platform-tests/pull/5188 |
| 10:39 | <beverloo> | ack, let me reply |
| 10:42 | <beverloo> | annevk, replied |
| 10:43 | <beverloo> | annevk, unrelated question, how'd I go about getting approval for https://github.com/w3c/web-platform-tests/pull/5094? |
| 10:44 | <annevk> | beverloo: if you get a review for that PR I can land it |
| 10:44 | <beverloo> | cool, thanks, I'll nag Jake |
| 12:29 | <tobie> | beverloo/annevk: so much boilerplate ffs |
| 12:41 | <annevk> | tobie: could use any.js, agreed, no need to swear about it though 😊 |
| 12:41 | <annevk> | Although I suppose that does not work for sw yet |
| 12:42 | <tobie> | annevk: to be clear, I was complaining about the state of things, not the PR |
| 12:43 | <tobie> | annevk: I don't know what any.js is, btw. Pointer? |
| 12:43 | <tobie> | annevk: I r+ the PR, btw. Do you want to merge it or shall I? |
| 12:44 | <annevk> | tobie: search for it on http://web-platform-tests.org/writing-tests/testharness.html |
| 12:44 | <tobie> | annevk: ty |
| 12:44 | <annevk> | tobie: I guess you can merge it, but if it can use .any.js that might be nice to do before landing |
| 12:48 | <tobie> | annevk: unclear from the doc |
| 12:48 | <tobie> | will check in #testing |
| 14:20 | <zcorpan> | TabAtkins: any ETA on the fingerprinting thing in bikeshed? |
| 16:10 | <jugglinmike> | JakeA: hello! Do you have a minute for a quick question about contributing to the Service Worker spec? |
| 16:11 | <jugglinmike> | I'm trying to learn how "terms defined by reference" are included in the `index.bs` file. |
| 16:11 | <jugglinmike> | I'm confused because I'm not seeing any entries for, e.g. "transforming" |
| 16:12 | <jugglinmike> | Does the Bikeshed utility have W3C references built in? |
| 16:13 | <annevk> | jugglinmike: oh, yes, it does |
| 16:14 | <annevk> | jugglinmike: there's a tool that collects all these terms from various documents and puts them in a central database |
| 16:14 | <annevk> | jugglinmike: not all standards are included, but the important ones are |
| 16:14 | <jugglinmike> | annevk: ah. I only just found https://tabatkins.github.io/bikeshed/ . Reading more about this now |
| 16:33 | <jugglinmike> | TabAtkins: I'm having some issues with Bikeshed, wondering if you can help. `bikeshed refs --text=transforming` returns successfully, but `bikeshed refs --spec promises-guide-1` crashes with "TypeError: coercing to Unicode: need string or buffer, NoneType found" |
| 16:33 | <jugglinmike> | running Python 2.7.12 in Ubuntu, installed according to the instructions published online |
| 16:34 | <TabAtkins> | Hm, that works for me, and I haven't changed anything about it in some time. |
| 16:34 | <TabAtkins> | When did you install? Was it a while ago? |
| 16:34 | <jugglinmike> | about an hour ago |
| 16:34 | <jugglinmike> | however |
| 16:35 | <TabAtkins> | Hm! |
| 16:35 | <jugglinmike> | oh, and this is obviously not a good idea: |
| 16:35 | <jugglinmike> | I am running at commit https://tabatkins.github.io/bikeshed/#installing |
| 16:35 | <jugglinmike> | that's not a sha |
| 16:35 | <jugglinmike> | I am running at commit 0466dfe0603d05075d063d910336a5796413ac9b |
| 16:36 | <jugglinmike> | because that is the commit used to build the latest version of the ServiceWorker specification, and Bikeshed at `master` crashes on build |
| 16:37 | <TabAtkins> | So the bug you're running into has been fixed since that commit. I appreciate being told when master is crashing on a spec. ^_^ |
| 16:37 | <jugglinmike> | I should have thought of this, but probably something has changed about the format of the external database in the time since the commit I am using |
| 16:37 | <annevk> | I thought JakeA had fixed ServiceWorker somehow, but I guess it regressed again :-/ |
| 16:37 | <TabAtkins> | Nothing about the db, it's about the querying function - it previously required a --text parameter accidentally. |
| 16:37 | <annevk> | TabAtkins: it seems like it crashes on ServiceWorker |
| 16:37 | <jugglinmike> | TabAtkins: I figured you might. I have been trying to get it working so that the issue I file is cogent |
| 16:37 | <annevk> | TabAtkins: cd ServiceWorker/docs |
| 16:37 | <annevk> | TabAtkins: bikeshed |
| 16:38 | <TabAtkins> | Meh, "shit is crashing, here's the repo/file" works *great* as an issue for me, fyi |
| 16:38 | <annevk> | TabAtkins: KeyError: 'biblio' |
| 16:38 | <jugglinmike> | in that case, annevk has you covered ^ |
| 16:38 | <annevk> | I guess I can let jugglinmike file, though really jungkees or JakeA should have done this |
| 16:38 | <jugglinmike> | I don't mind filing |
| 16:38 | <jugglinmike> | It'll give me something to show for the morning :P |
| 16:39 | <TabAtkins> | Checking it out now, gimme a sec. |
| 16:39 | <annevk> | I guess they haven't done anything for 28 days, maybe that's why stuff went weird |
| 16:45 | <jugglinmike> | here's all I know https://github.com/tabatkins/bikeshed/issues/968 |
| 16:45 | <TabAtkins> | I found the error, fixing it now. |
| 16:47 | <TabAtkins> | And done. |
| 16:48 | <TabAtkins> | Thanks for the report, I'd left out one of the linktypes from a list, so it was throwing a KeyError when I went to look for it. ^_^ |
| 16:49 | <jugglinmike> | Awesome, thanks TabAtkins! |
| 16:50 | <TabAtkins> | Crashes mean I've definitely done something wrong, and it's usually much easier for me to diagnose it than for you to, so feel free to file an issue *immediately* when it happens. All I need is a file I can repro the crash with, I'll take care of the rest. |
| 16:50 | <jugglinmike> | Roger that |
| 16:50 | <jugglinmike> | Now I have a workflow question. Might be better for Jake, but maybe you can speak to how this is generally handled by Bikeshed users |
| 16:52 | <jugglinmike> | Re-generating the spec using `master` causes changes to the document that are unrelated to my patch. Should I pick around those for my pull request? Or maybe make a dedicated commit for them before introducing my changes/ |
| 16:52 | <jugglinmike> | (And do many people check the compiled document into their repository?) |
| 16:52 | <TabAtkins> | Up to you. Presumably they're formatting or other minor things? Eyeballing the changes is usually good just to make sure everything's still generating fine. |
| 16:53 | <TabAtkins> | imo, either check the generated file in, or have a CI job that compiles for you and checks it in somewhere else. |
| 16:54 | <jugglinmike> | yeah, I'd prefer the latter. But I'm just some guy |
| 16:55 | <annevk> | jugglinmike: yeah, service workers should setup tooling so you only need to modify .bs |
| 16:56 | <annevk> | jugglinmike: but until they do, including the generated HTML is generally the way to go, although it creates more rebasing hassle than you want |
| 16:58 | <jugglinmike> | I think I'll pick it out and submit it separately. The annoying thing about this is the "last updated" information. It guarantees merge conflicts |
| 17:00 | <annevk> | jugglinmike: at that point you shouldn't include it at all |
| 17:00 | <annevk> | jugglinmike: you don't want to mess with generated output |
| 21:50 | <JakeA> | annevk: happy to set up a bot to build the spec. Who's doing this already? Is there a best-practice config? |