| 04:25 | <jpdevries> | I have a question about if something has been, or perhaps would be, considered for the Notifications API. I think the implicit accessibility provided by such an API makes it an appealing way for web apps to display notifications for when async actions have succedded or failed without having to go through making an HTML element accessible themselves. Thing is, I just realized that Nofications don't seem to display when users are in "Do Not Dist |
| 04:25 | <jpdevries> | but my question is this. Would it make sense for the Notifications API to support some sort of "assertive" option that notifies them anyways? I understand this could be abused, but I think there may be ways to circuvment that (it only works if hte notification was dispatched from something like a "click" event) |
| 04:47 | <annevk> | jpdevries: in that case could you not just display something in the app? |
| 04:49 | <jpdevries> | Ya certainly, but I think of the Notifications API as being nice for this as it comes with implicit accessibility. |
| 04:59 | <jpdevries> | but maybe i'm just being lazy ;) |
| 05:03 | <annevk> | Notifications are never going to be a guarantee |
| 05:04 | <annevk> | I personally have most of m disabled |
| 05:05 | <jpdevries> | that's good to know. for some reason, i expected a notification from an interface i'm interacting with to be more than prominent than like, a news notification. but i see now it makes sense they wouldn't be guaranteed |
| 07:26 | <jochen__> | annevk: ! |
| 07:26 | <jochen__> | annevk: please don't go away from the suborigin discussion |
| 07:29 | <annevk> | jochen__: I have the feeling my input is not getting duly considered, if that makes sense |
| 07:29 | <annevk> | jochen__: or maybe my questions can only be addressed by mkwst? |
| 07:30 | <annevk> | jochen__: there's a lot of activity on the minutia, but high-level design questions just linger |
| 07:31 | <jochen__> | annevk: I just took this work over from jww, so I'm still ramping up |
| 07:31 | <annevk> | jochen__: one question I've had since the start for instance is how this would deal with permissions and nobody has really given me a concrete answer thus far |
| 07:32 | <annevk> | jochen__: say I grant example.com the ability to do notifications, does example.com/suborigin1 get them too? If not, how does it ask for permissions without confusing the user? |
| 07:33 | <jochen__> | annevk: from my point of view, I'd like to hide the fact that suborigins are a thing from users, so I'd grant all suborigins the permission if the origin has it |
| 07:34 | <annevk> | jochen__: and a suborigin would ask on behalf of the origin too? |
| 07:34 | <jochen__> | correct |
| 07:34 | <annevk> | jochen__: I think that model makes sense, but mkwst and jww gave different answers at times |
| 07:35 | <jochen__> | that's possible :) |
| 07:35 | <jochen__> | so, how can we make sure that esp. the platform affecting / security model changes are understood? |
| 07:36 | <jochen__> | we've scheduled an update for the next WebAppSec phonecall, and I wanted to sync with devd before |
| 07:36 | <annevk> | I think a good first step is to file "Suborigin integration" issues against all standards that are affected |
| 07:36 | <jochen__> | maybe it makes sense for you to join the sync as well? |
| 07:36 | <annevk> | So more people know this is a thing and can try to think through the implications |
| 07:36 | <jochen__> | good point |
| 07:37 | <jochen__> | I expect that that's HTML for postMessage / MessageEvent & window.origin & origin definition |
| 07:37 | <jochen__> | is CORS handled as part of fetch now? |
| 07:39 | <annevk> | jochen__: yes, CORS is in Fetch |
| 07:40 | <annevk> | jochen__: I'd rather not join a call, happy to study things async |
| 07:41 | <annevk> | jochen__: I'd expect issues against HTML, Fetch, Cookies (no idea where that is tracked though, private mkwst repo?), and maybe URL |
| 07:41 | <jochen__> | yeah, for cookies, the idea is to mark a browsing context in a suborigin as cookie-averse |
| 07:41 | <jochen__> | that one seems straight forward |
| 07:41 | <jochen__> | permissions would also be part of HTML? |
| 07:42 | <annevk> | jochen__: what about same-origin cookies? |
| 07:42 | <annevk> | jochen__: permissions is https://w3c.github.io/permissions/ |
| 07:42 | <annevk> | jochen__: presumably you'd want same-suborigin cookies for the same reason we introduced same-origin cookies |
| 07:43 | <jochen__> | annevk: the main problem is that on the first request, the browser doesn't know which suborigin to expect |
| 07:43 | <annevk> | jochen__: although maybe that isn't possible since the suborigin is not known at the time of request |
| 07:43 | <annevk> | heh |
| 07:43 | <jochen__> | annevk: so we could either send all cookies (but that's potentially a large list) or none and rerequest the URL after the suborigin header was recevied (but that's slow) |
| 07:44 | <jochen__> | annevk: so I think we'll just not have suborigin specific cookies, and document.cookies will not return any cookies for js |
| 07:44 | <annevk> | jochen__: if https://wicg.github.io/origin-policy/ is a thing we could make it known ahead of time in theory |
| 07:44 | <jochen__> | true |
| 07:44 | <jochen__> | my feeling is that we might be able to punt that until there are actually sites that would need that |
| 07:45 | <jochen__> | it seems that the cases we have so far would work with monkey patching document.cookie to store stuff in localStorage |
| 07:46 | <annevk> | and cookies set by the server would still be transmitted since we don't know about suborigins at time of request |
| 07:46 | <jochen__> | right |
| 07:46 | <jochen__> | all other storage things, however, would be per suborigin |
| 07:47 | <jochen__> | e.g. IDB, localStorage, web database |
| 07:48 | <annevk> | Ah, I missed IDB in the list above of needing integration |
| 07:48 | <annevk> | Maybe https://storage.spec.whatwg.org/ needs to take this into account somehow too |
| 07:49 | <annevk> | Even if you get the persistent permission for an entire origin, applications might want to persist on a per-suborigin basis |
| 07:51 | <annevk> | jochen__: I think part of the problem is that a lot of the motivation is upgrading legacy apps, but not moving them to a subdomain; so it's unclear if we're just adding a lot of complexity to the platform for legacy apps, or if there's also forward looking reasons for all this |
| 07:51 | <jochen__> | it's not just about legacy apps |
| 07:52 | <jochen__> | one reason that folks don't want to move stuff to subdomains is that they don't want to prompt users N times for the same permission |
| 07:52 | <jochen__> | but it's a fair point |
| 07:52 | <annevk> | dglazkov: if you enable comments on https://docs.google.com/document/d/18qpNBY3Xm2svzBSAgOJk_Kkb_iRJXCsZQO4Oa3wv3n4/edit I might correct some typos |
| 07:53 | <annevk> | jochen__: ah permissions, of course; I guess that at least provides sufficient motivation to make this work well and solve all the edge cases too |
| 07:56 | <jochen__> | I started a discussion on public-webappsec about introducing a concept of site affiliation |
| 07:56 | <jochen__> | maybe via origin policy |
| 07:56 | <jochen__> | that would be another option to share permissions with multiple sites |
| 07:57 | <jochen__> | the downside is that we didn't ask the user whether to grant a permission for the current origin and all affiliated sites |
| 07:57 | <annevk> | I unsubscribed from public-webappsec since it had too many announcement emails |
| 07:58 | <jochen__> | so I don't think we could just pass on permissions without re-prompting, and the prompt would probably look odd (including a potentially long list of domains), and what should we do if the list of affiliated sites changes |
| 07:59 | <annevk> | In principle a top-level site can already share permissions with anyone it embeds without telling the user |
| 07:59 | <annevk> | But only for the duration of that visit |
| 08:00 | <annevk> | Yeah, not sure I have any good suggestions there, UX for that would be really tough |
| 08:00 | <annevk> | Permissions UX is already impossibly hard to get right |
| 08:01 | <jochen__> | so anyways |
| 08:01 | <jochen__> | I've noted filing issues on my todo list |
| 08:01 | <jochen__> | might not happen this week, as I'm at a conference |
| 08:02 | <annevk> | Thanks, and enjoy the conf |
| 08:40 | <zcorpan> | nox: I'm here now |
| 08:40 | <nox> | zcorpan: I took a decision myself. :) |
| 08:41 | <nox> | zcorpan: I am currently splitting the tests in unitless-length.html, |
| 08:41 | <nox> | zcorpan: to test per property and per quirky value, |
| 08:41 | <nox> | instead of grouping all properties in a single quirky value test. |
| 08:41 | <zcorpan> | nox: (╯°□°）╯︵ ┻━┻ |
| 08:41 | <nox> | You don't like that? :( |
| 08:41 | <zcorpan> | nox: just kidding :-) |
| 08:41 | <nox> | Ah. :) |
| 08:42 | <zcorpan> | sounds good |
| 08:42 | <nox> | zcorpan: Surprisingly, |
| 08:43 | <nox> | zcorpan: with the quirk in Servo, I expected unrelated tests to pass, |
| 08:43 | <nox> | tests that would have been using the quirk syntax by mistake, |
| 08:43 | <nox> | turns out they were not, and I should not expect the worst of wpt. :P |
| 08:43 | <nox> | there were not* |
| 08:43 | <nox> | Too many rebases break my English. |
| 08:44 | <zcorpan> | hehe, well good then that there are tests specifically for unitless |
| 08:46 | <nox> | zcorpan: Yep, Servo all passes them, except for some top/bottom failures specific to macOS, unrelated to the quirk itself. |
| 08:46 | <zcorpan> | nox: so for {input:"-\\31 "}, the test expects it to not be applied, no? |
| 08:58 | <nox> | zcorpan: Btw, https://github.com/servo/servo/pull/16609/commits/b60049cbfc2f38aa4d2294a98a61d720df807d63 |
| 08:58 | <nox> | zcorpan: Yes, these don't parse. |
| 09:27 | <Emil> | Hi |
| 09:31 | <annevk> | Emil: heya |
| 09:32 | <zcorpan> | nox: 👍 |
| 10:09 | <nox> | zcorpan: Can you confirm that /html/semantics/interactive-elements/the-dialog-element/centering.html is totally unrelated to that quirk? |
| 10:12 | <zcorpan> | nox: yes. that doesn't use unitless values and doesn't use quirks mode |
| 10:18 | <nox> | zcorpan: Thanks. |
| 11:45 | <smaug> | zcorpan: how is https://drafts.csswg.org/cssom-view/#dom-mouseevent-offsetx supposed to work if event is re-dispatched |
| 11:52 | <annevk> | smaug: basically that needs to be defined as part of the MouseEvent definition and dispatch itself |
| 11:52 | <annevk> | smaug: the current approach doesn't really work |
| 11:52 | <smaug> | not necessarily |
| 11:52 | <smaug> | sure |
| 11:52 | <smaug> | but the second dispatch could also just keep using pageX/Y |
| 11:55 | <smaug> | zcorpan: looks like blink doesn't follow the pageX/Y behavior |
| 12:25 | <zcorpan> | smaug: hmm. IIRC there's an open bug about the check for the dispatch flag being bogus |
| 12:26 | <smaug> | I filed couple of bugs |
| 12:28 | <zcorpan> | smaug: ok. i don't have this paged in right now and don't have a particular opinion about how it should work (other than it should be web compatible and interoperable) |
| 12:28 | <smaug> | the testcase didn't work in Edge, so don't know yet what it does |
| 12:37 | <nox> | zcorpan: I have a question. |
| 12:37 | <nox> | zcorpan: Would unitless-length.html still work if it used position:absolute? |
| 12:37 | <nox> | Trying to understand why I have intermittent failures in Servo and how to limit them. |
| 12:40 | <zcorpan> | nox: yeah i think absolute would work as well. everything still passes in chromium with that change |
| 12:40 | <nox> | zcorpan: That being said, |
| 12:40 | <nox> | I have intermittents in the color quirk test too, so... |
| 12:58 | <annevk> | Domenic: you awake? |
| 12:58 | <Domenic> | annevk: reading email in bed, but yeah |
| 12:59 | <annevk> | Domenic: do we want to test the various views? |
| 12:59 | <annevk> | Domenic: it seems we need to generalize testSharingViaIncrementerScript and then update all callsites |
| 13:00 | <annevk> | Domenic: looking at SAB tests |
| 13:01 | <Domenic> | annevk: yeah I got a bit lazy on that... It'd be ideal to test one typed array, DataView, and maybe { nested: { view: [ta] } } |
| 13:01 | <Domenic> | the shared incrementer would probably be the right way to test, yeah. |
| 13:05 | <Emil> | Anyone here experienced with websockets? |
| 13:06 | <annevk> | Domenic: there were a couple of places I was surprised you didn't just pass the view to postMessage() as a way to get some variety, though they didn't seem super easy to change either |
| 13:07 | <annevk> | Domenic: I'll have a look to see how far I get with adding some at least |
| 13:07 | <annevk> | Domenic: I also left a couple of basic questions in the PR |
| 13:07 | <Domenic> | annevk: yeah, getting to them now |
| 13:08 | <Emil> | I'm experiencing an issue where wss.send("perkele".repeat(9)) from a browser works just fine according to the frame spec as outlined in the rfc, but wss.send("perkele".repeat(10)) results in garbage |
| 13:12 | <nox> | zcorpan: Do you see any way to test the quirk without using getComputedStyle? |
| 13:18 | <annevk> | Emil: sounds like you hit a bug of sorts |
| 13:20 | <annevk> | Emil: might be worth checking bufferedAmount but with such small amounts of data there really shouldn't be a problem |
| 13:21 | <nox> | zcorpan: Could we use data: URLs for the iframes contents, instead of using open/write/close? |
| 13:22 | <annevk> | nox: not same-origin |
| 13:22 | <zcorpan> | nox: that would get an opaque origin so the script couldn't getComputedStyle in it. would need postMessage? |
| 13:22 | <nox> | Oh right. |
| 13:22 | <annevk> | could use srcdoc maybe? |
| 13:22 | <nox> | zcorpan: Seems like our issue is that we reflow problems and we should wait for the iframe's load event. |
| 13:22 | <zcorpan> | srcdoc is always standards mode |
| 13:22 | <nox> | zcorpan: Do you mind if I patch the tests to do this? |
| 13:23 | <zcorpan> | nox: to do what? |
| 13:23 | <zcorpan> | oh wait for onload |
| 13:23 | <nox> | zcorpan: Run the tests in q.contentWindow.onload or something. |
| 13:24 | <zcorpan> | SGTM |
| 13:24 | <zcorpan> | could add a separate test for calling getComputedStyle during page load, if that's buggy? |
| 13:25 | <Emil> | annevk: my buffer is 4k in size |
| 13:26 | <Emil> | which means it shouldn't break at that :/ |
| 13:27 | <zcorpan> | Emil: clearly the issue is you're swearing repeatedly in the message :-P |
| 13:28 | <Emil> | zcorpan: hehe |
| 13:28 | <Emil> | if only :/ |
| 13:29 | <annevk> | Emil: I meant webSocketInstance.bufferedAmount, if that wasn't clear |
| 13:29 | <annevk> | Emil: does it happen in all browsers? |
| 13:30 | <Emil> | yeah |
| 13:31 | <Emil> | meaining I'm doing something wrong |
| 13:31 | <zcorpan> | Emil: so perkele * 9 is 63. perkele * 10 is 70, which means it won't fit in a "small" frame, and will instead use extended payload length |
| 13:31 | <zcorpan> | Emil: does the server implementation support such frames? |
| 13:31 | <Emil> | zcorpan: but isn't the limit 125 bytes? |
| 13:32 | <Emil> | and anycase, yeah, I have extended payload length support |
| 13:32 | <zcorpan> | Emil: huh yeah. I thought it was 64 or something. ok |
| 13:34 | <Emil> | Is there a situation in which the ws frames don't adhere to the 2 byte header, 0/2/8 bytes extended payload, 4 bytes mask, payload-data |
| 13:34 | <Emil> | from browser to server |
| 13:34 | <nox> | zcorpan: https://github.com/servo/servo/pull/16618#issuecomment-297409757 Hah! |
| 13:34 | <nox> | No need to change the test, just ping the right person on IRC. :P |
| 13:35 | <nox> | (The link was supposed to be to a PR, not a comment in it.) |
| 13:35 | <zcorpan> | Emil: messages could be fragmented into multiple frames, but i think shouldn't happen for such short messages |
| 13:36 | <Emil> | zcorpan: but they still follow the frame format |
| 13:36 | <zcorpan> | yeah |
| 13:36 | <Emil> | right? |
| 13:36 | <Emil> | And because I am only reading frames |
| 13:36 | <Emil> | that shouldn't be an issue |
| 13:38 | <zcorpan> | Emil: do you know what goes over the wire? (I guess easier to debug without TLS) |
| 13:39 | <Emil> | zcorpan: hm? |
| 13:39 | <Emil> | I am capturing the raw data in C |
| 13:40 | <Emil> | nginx is stripping the TLS off |
| 13:40 | <zcorpan> | Emil: ok. so what data do you get? |
| 13:40 | <Emil> | here's a raw dump https://emil.fi/jako/koodi/ws_dump_2017-04-26_15:56:14_+0300_4 |
| 13:41 | <Emil> | that's the data received through the socket without the HTTP handshake |
| 13:41 | <Emil> | I can add the HTTP handshake, too, if required |
| 13:44 | <annevk> | Domenic: I'm probably not going to get to generalizing the tests today after all :/ |
| 13:50 | <Emil> | zcorpan: Any success? |
| 13:53 | <zcorpan> | Emil: I don't have a websocket implementation at hand to run it through... I started comparing the bits with the spec's framing but that isn't very efficient ^_^ |
| 13:53 | <zcorpan> | Emil: the first byte looks OK right? |
| 13:54 | <Emil> | zcorpan: I get just fine data with a message like: 2017-04-26 16:54:05.617 +0300 perkele |
| 13:54 | <Emil> | or perkele repeated 9 times |
| 13:54 | <Emil> | but perkele repeated 10 times and it breaks :D |
| 13:55 | <Emil> | hmm, I'll write a ws decoder |
| 13:55 | <Emil> | for files |
| 13:56 | <zcorpan> | very curious. dooes browser's devtools help? (opera 12 had reasonable error messages in the console, but i guess they only help if the client receives something unexpected) |
| 13:59 | <Emil> | No, they don't show the actual raw data |
| 13:59 | <Emil> | just payload |
| 14:30 | <zcorpan> | ok |
| 16:43 | <Emil> | hehe |
| 16:43 | <Emil> | shame on me |
| 16:43 | <Emil> | next time have the right god damn masks you smarty pants |
| 17:14 | <annevk> | Domenic: you okay with me reintroducing the BroadcastChannel test I wrote? |
| 17:14 | <annevk> | Domenic: I'll look into abstracting for multiple views tomorrow |
| 17:14 | <annevk> | Domenic: and update the corresponding shared memory blog post |
| 17:14 | <annevk> | Domenic: anything else? |
| 17:28 | <Domenic> | annevk: I haven't looked at the Broadcast channel spec fix yet but I assume you got it right there. That does sound like all we need. Maybe I'll rebase and do a last review of the remaining PR. |
| 17:29 | <annevk> | Domenic: the remaining PR is already rebased and was already reviewed I think |
| 17:30 | <annevk> | Domenic: but we don't have the various view tests |
| 17:30 | <annevk> | Domenic: which should be doable, just some abstraction work and making sure everything still runs after the changes have been made |
| 17:30 | <Domenic> | annevk: I meant the spec PR |
| 17:30 | <annevk> | Domenic: yes, I did too |
| 17:30 | <Domenic> | Ah ok |
| 17:31 | <Domenic> | Note you can test in Chrome by flipping an extra flag in about:flags |
| 17:31 | <annevk> | Ah okay |
| 18:20 | <aklein> | Domenic: have you been in contact with Constellation, jonco, Edge folks about <script type=module> spec issues? |
| 18:21 | <Domenic> | aklein: you mean the bugfixes around errors and such? Not really, sorry to say. |
| 18:21 | <aklein> | Domenic: makes me a little uneasy |
| 18:22 | <Domenic> | aklein: my view was that we were working out all the bugs, nothing controversial, and it'd be nicer to present them with a "hey we fixed all the bugs and have tests" instead of keeping them incrementally updated. But maybe more communication would be good. |
| 18:23 | <aklein> | Domenic: that seems fine too |
| 18:23 | <aklein> | I don't think most of the issues so far are controversial |
| 18:23 | <aklein> | I'm mostly curious whether any of them even noticed any of this |
| 23:01 | <zewt> | jesus, firefox just installed an update automatically even though I have that turned off |
| 23:02 | <zewt> | there's a name for programs that install remote code on your computer without permission, and it's not "browser" |