| 07:25 | <annevk> | promise_test + async/await is really quite nice |
| 07:25 | <annevk> | I'm still not a 100% confident I do it correctly all the time, but it seems to work... |
| 07:42 | <annevk> | TimothyGu: Domenic: I finally created a "topic: document lifecycle" label, feel free to sprinkle it around; I guess it's kinda conflicting with navigation, but navigation doesn't naturally cover unload and such |
| 11:13 | <annevk> | We haven't really done memes in a while and I'm not even sure this is correct, but... https://irccloud.mozilla.com/file/fVjttBbv/hodor.jpg |
| 11:14 | <annevk> | https://irccloud.mozilla.com/file/3wvdQXda/hodor%20take%202.jpg |
| 11:14 | <nox> | annevk: Ah ah ah ah ah. |
| 11:14 | <nox> | annevk: Are people trying to change it? |
| 11:15 | <annevk> | nox: all the fricking time |
| 11:15 | <nox> | TIL, what a wonderful world we live in. |
| 11:15 | <annevk> | mostly on edge cases, though recently there was a thread about obsoleting it altogether |
| 11:16 | <nox> | Oh, Edge doesn't respect the policy? |
| 11:16 | nox | hides for this overused pun. |
| 11:17 | annevk | withholds a baguette |
| 11:17 | <nox> | Nooooooooooooooooooo |
| 11:19 | <annevk> | So that's an effective technique? Might be able to get document.open() fixed in Servo after all 😛 |
| 11:19 | <nox> | Ah ah ah ah. |
| 11:20 | <nox> | annevk: Fortunately, when I implemented it I skipped the whole "let's create a new Window" IIRC. |
| 11:20 | <annevk> | smart |
| 11:20 | <nox> | So it shouldn't be *that* hard to fix it (famous last words, probs). |
| 11:27 | <Ms2ger> | nox, so did the smup land? |
| 11:27 | <nox> | Ms2ger: Yes. |
| 11:27 | <nox> | Ms2ger: I'm currently looking at my PRs against WPT right now. :) |
| 11:27 | <Ms2ger> | When's the next one? 2021? |
| 11:28 | <nox> | I like how multiple meanings of "against" fit here. |
| 11:28 | <nox> | Literally made it worse for Servo. |
| 11:35 | <nox> | Mmh, most of my changes have disappeared already. |
| 11:36 | <nox> | Made https://github.com/web-platform-tests/wpt/pull/12672 nonetheless. |
| 13:52 | <annevk> | yoav: I'm not sure how to reply to https://github.com/whatwg/fetch/issues/800#issuecomment-415760321 |
| 13:52 | <annevk> | yoav: my main concern is that I don't understand what model you all want |
| 13:53 | <annevk> | yoav: (in that there are multiple somewhat contradictory requirements) |
| 13:53 | <annevk> | yoav: I'm also concerned about adding exceptions to the same-origin policy |
| 13:55 | <annevk> | yoav: I haven't really considered the privacy leakage aspects enough to have an informed opinion there; I suspect you're probably right that 1P can leak those however (assuming there's no way 1P and 3P would ever get different intel) |
| 13:55 | <annevk> | yoav: hope that helps |
| 13:56 | <yoav> | OK. From my perspective the SOP concern is not related to this issue, but to https://github.com/whatwg/fetch/pull/725 |
| 13:56 | <yoav> | annevk: would that be correct? Or are there SOP concerns that are specific to the redirect scenario you mentioned? |
| 13:58 | <annevk> | yoav: it's a problem with Client Hints in general, and I regret not pushing harder earlier on; I also note that that PR is blocked on the model not being defined |
| 13:59 | <annevk> | yoav: again, it'd help if more implementers are on board here, I don't think we had that requirement when we initially added Client Hints |
| 14:00 | <yoav> | annevk: which requirement? to safelist the headers? To not expose CH to 3P unless 1P opts in? |
| 14:01 | <annevk> | yoav: to have multiple implementers on board |
| 14:01 | <yoav> | annevk: oh, ok |
| 14:05 | <annevk> | I guess reading some past discussions Mozilla was halfheartedly on board, though not with all concerns addressed |
| 14:05 | <annevk> | But also back then the header exploits were not seen as important |
| 14:05 | <annevk> | Sigh |
| 14:06 | <annevk> | yoav: I think the SOP concerns can probably be addressed by adequately restricting the value space of the headers (this is already done in prose somewhat, but I doubt it's tested) |
| 14:07 | <annevk> | yoav: so I guess I wouldn't focus too much on my SOP concerns |
| 14:08 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=1263446 has all the past Mozilla discussion (also follow the dev.platform link) FWIW |
| 14:08 | <annevk> | There's also some talk there of restricting this to H/2 / HTTPS |
| 14:08 | <annevk> | Which I think is planned, but not in the spec yet |
| 14:09 | <annevk> | (This situation does make me appreciate our new setup of multiple implementers, tests, etc.) |
| 14:21 | <nnyby> | Is it possible to differentiate between a range input's knob vs its slider track on the mousedown event? more details here: https://stackoverflow.com/q/52006259/173630 |
| 14:24 | <Ms2ger> | Since the spec doesn't define what it looks like, I doubt it |
| 14:24 | <nnyby> | alright, thanks. |
| 14:26 | <zcorpan> | nnyby: what's the use case? why do you want this? |
| 14:28 | <nnyby> | zcorpan: heh well, it's actually related to your helpful answer you gave me yesterday. I want to disable your oninput limiter when the user clicks the knob of the slider, so it's freely draggable. and only allow your oninput limiter to take effect when the surrounding slider track is clicked. |
| 14:30 | <nnyby> | the more general use case is that this is for some astronomy simulations i'm working on - converting from flash to html/javascript. The astronomer really likes the way the original sliders behave. (flash required: https://cse.unl.edu/~astrodev/flashdev2/transitSimulator/transitSimulator017.html) |
| 14:30 | <zcorpan> | nnyby: you can compare the new value to the old value, and do nothing if it's near enough |
| 14:30 | <nnyby> | zcorpan: ahh yeah. that would be a good workaround. i'll try that. thanks |
| 14:31 | <zcorpan> | it might do the wrong thing if you move fast or if there's a lag, though. |
| 14:41 | <nnyby> | ah sweet.. i think I got it. That solution kind of worked, but I'm getting better behavior with just tracking the dragging state with mousedown, mouseup, and mousemove. |
| 14:58 | <annevk> | zcorpan: https://github.com/whatwg/html/pull/3914 needs rebasing; presumably due to the padding change |
| 15:04 | <annevk> | zcorpan: could you document whatwg/fieldset in https://github.com/whatwg/meta/blob/master/GITHUB-TEAMS.md ? |
| 15:07 | <zcorpan> | https://github.com/whatwg/meta/pull/105 |
| 15:23 | <MikeSmith> | FYI I just set up https://arcane-cove-57093.herokuapp.com/multipage/ for demo’ing/testing sample HTML spec output with MDN annotations/links added |
| 15:25 | <MikeSmith> | e.g., scroll down in https://arcane-cove-57093.herokuapp.com/multipage/semantics.html#the-link-element |
| 15:29 | <dtapuska> | annevk: Re: https://github.com/whatwg/fullscreen/pull/129#issuecomment-415650122 I think that is the inverse of what we want... ie navigationUI would have to default to true then |
| 15:33 | <annevk> | dtapuska: you want to show UI by default? |
| 15:34 | <annevk> | dtapuska: I misunderstood in that case |
| 15:35 | <annevk> | dtapuska: then disableNavigationBar would make sense, but that does not match existing impl afaik |
| 15:38 | <dtapuska> | annevk: I'm fine with that.. what do you mean it doesn't match the current impl? |
| 15:38 | <dtapuska> | annevk: requestFullscreen() and webkitRequestFullscreen() behave slightly differently in Chrome in this respect |
| 15:39 | <dtapuska> | annevk: we'd like to use unprefixing and providing an option as a catalyst to change this |
| 15:43 | <annevk> | dtapuska: to start defaulting to UI enabled? So I’m a little worried about other implementers. Are they all on board or do we need a tri-state as foolip suggested? |
| 15:44 | <dtapuska> | annevk: Samsung browser already does this by default for webkitRequestFullscreen() |
| 15:44 | <dtapuska> | annevk: and nobody has raised issues in the past regarding this |
| 15:47 | <annevk> | dtapuska: Samsung isn’t typically tested |
| 15:48 | <annevk> | Also for a change like this explicit consent is needed |
| 15:55 | <dtapuska> | annevk: explicit consent? The navigation bar appears on some Android devices. Are we actually understanding the same thing?. The back/forward/home buttons at the bottom on some Android devices are overlays... and on some it is always taken as space. This is just asking to hide them if it can but defaulting to not hiding them. A user agent should be free to choose its own default. So perhaps this needs to not be boolean |
| 15:58 | <annevk> | dtapuska: I think we are roughly understanding the same thing |
| 16:03 | <dtapuska> | annevk: do we need to provide a default value for the dictionary? WebIDL allows this and there is no guidance on https://w3ctag.github.io/design-principles/ regarding this |
| 16:04 | <annevk> | dtapuska: not for the dictionary argument (that's always {}) |
| 16:04 | <annevk> | dtapuska: for the dictionary member it's optional, but if you want to make this an enum I wouldn't allow undefined and just make one of the enum values the default |
| 16:05 | <annevk> | dtapuska: the main risk I'm seeing with this API is that developers start assuming some default, so "auto" and "omit" seems clearer to me true/false |
| 16:05 | <annevk> | dtapuska: that'd also allow for "include" if at some point all UAs agree that requesting some UI is reasonable |
| 16:06 | <dtapuska> | annevk: off the top of your head do you have an example API to model after? |
| 16:07 | <annevk> | dtapuska: no, but I can help with the IDL |
| 16:09 | <annevk> | dtapuska: dictionary RequestFullscreenInit { FullscreenNavigationUI navigationUI = "auto"; }; enum FullscreenNavigationUI { "auto", "omit" }; |
| 16:09 | <annevk> | dtapuska: if you meant something else, lmk |
| 16:11 | <dtapuska> | annevk: ya that looks ok |
| 16:25 | <annevk> | dtapuska: feature testing can be done with requestFullScreen({ get navigationUI() { throw 1 } }) fwiw but does require waiting one microtask |
| 16:26 | <annevk> | Seems acceptable though |
| 16:27 | <dtapuska> | annevk: there is no downside to always requestFullscreen({}); since it is the first optional dictionary |
| 16:28 | <annevk> | dtapuska: you still might wanna know whether a particular feature is supported before calling the method though |
| 16:28 | <annevk> | (assuming we're adding more over time) |
| 16:28 | <annevk> | (this wouldn't quite work if we ever added "include" unfortunately) |
| 16:30 | <dtapuska> | annevk: which I wonder if we should put "include" there from the start.. also "auto", "show", "hide" are more intuitive to me |
| 16:35 | <annevk> | dtapuska: yeah, maybe, I guess it depends on what implementers say |
| 16:35 | <annevk> | dtapuska: we need two engines interested |
| 16:35 | <annevk> | dtapuska: your names sgtm |
| 16:56 | <annevk> | wanderview: so given request URL x and service worker response URL y; shouldn't y win? |
| 16:57 | <annevk> | wanderview: I guess we settled on x since that's what I'm seeing? I guess I should read the spec again, but prolly Monday |
| 17:40 | <annevk> | wanderview: so per Fetch's main fetch it seems it should be y |
| 17:40 | <annevk> | It's rather frustrating this isn't implemented that way still, I wonder at what point it'll be too late |
| 17:45 | <wanderview> | annevk: it should be Response url y |
| 17:45 | <wanderview> | annevk: and that should be implemented in firefox |
| 17:56 | <annevk> | wanderview: at least for https://github.com/web-platform-tests/wpt/pull/12680 I get x |
| 17:57 | <annevk> | wanderview: I get resources/test not resources/test.txt |
| 17:58 | <annevk> | wanderview: gonna take a break now, but would appreciate feedback on that |
| 17:58 | <wanderview> | annevk: is your test using skipWaiting() somewhere to control the current window? or how is your fetch() being made from a controlled client? |
| 17:59 | <wanderview> | I think you need to make an iframe that the service worker controls |
| 17:59 | <wanderview> | and do the fetch from there |
| 19:20 | <annevk> | wanderview: thanks, sorry about that |
| 19:21 | <wanderview> | np |
| 20:37 | <TimothyGu> | Anyone knows who're the right people to CC for https://github.com/whatwg/html/pull/3960? |
