| 01:20 | <kochi> | annevk: 3day conf schedule sounds reasonable. |
| 03:32 | <Domenic> | Hmm. https://github.com/WebAssembly/design/issues/1164 |
| 03:38 | <MikeSmith> | oh lord |
| 03:38 | <MikeSmith> | belly laughs |
| 03:39 | <MikeSmith> | OP’s comments start out great and just keep getting better |
| 03:43 | <GPHemsley> | why are people engaging in good faith when OP clearly is not? |
| 03:45 | <MikeSmith> | I think they're testing to see if it's a bot |
| 04:06 | <KiChjang> | "i read and write wasm" really? |
| 04:10 | <othermaciej> | I think OP is posting in good faith but is misguided (and kind of opinionated) |
| 04:39 | <Domenic> | I think I agree with othermaciej. I mostly feel bad for the 786 inboxes who get one email per post in that thread. |
| 09:24 | <annevk> | Oh my, our Code of conduct notice on every repo lacks an Oxford comma |
| 09:24 | <annevk> | How did that even happen? |
| 09:41 | <nox> | That's because Oxford commas shouldn't exist. |
| 09:49 | <annevk> | Lies |
| 10:41 | <tobie> | annevk, smaug____ : I think the desired syntax is this.[[prop]] |
| 10:42 | <smaug____> | tobie: looks reasonable. (I've given up objecting [[foo]] syntax) |
| 10:43 | <smaug____> | tobie: in IntersectionObserver spec the issue is that root is also an attribute in the interface |
| 10:44 | <smaug____> | so this.root = some value is odd. this.[[root]], if defined what [[]] means, would be good. |
| 10:45 | <tobie> | smaug____: yup. It's at the top of my todo list |
| 10:46 | <smaug____> | great |
| 10:46 | <tobie> | smaug____: https://github.com/heycam/webidl/issues/258 |
| 10:46 | <tobie> | arguably, it's been at the top of my todolist for a while :-( |
| 10:47 | <smaug____> | tobie: I assume "slot children;" isn't going to happen |
| 10:48 | <smaug____> | Since that would pollute the API declaration, make it harder to read. |
| 12:13 | <JakeA> | annevk: thinking about request.navigationInfo.history vs request.navigationHistory. Happy to avoid a tear-off object, but navigationHistory doesn't sound like a boolean to me. isReloadNavigation, isHistoryNavigation? |
| 12:13 | <JakeA> | This is https://github.com/w3c/ServiceWorker/issues/1167#issuecomment-350238893 btw |
| 12:48 | <annevk> | JakeA: hmm, maybe tear-off is okay; I'm actually more interested in the question of getting rid of the technical debt before we expose more potentially incorrect APIs |
| 12:48 | <annevk> | JakeA: not a big fan of quicksand API design |
| 12:52 | <JakeA> | annevk: which parts are you worried about? It seems straight forward to as we already do different things for reload & back/forward elsewhere |
| 12:52 | <annevk> | JakeA: basically navigation and history not being defined in interoperable detail |
| 12:52 | <JakeA> | annevk: eg there's already https://w3c.github.io/navigation-timing/#idl-def-navigationtype |
| 12:52 | <annevk> | JakeA: see the many many issues against whatwg/html on those subjects |
| 12:53 | <annevk> | JakeA: the Performance WG is rather notorious for designing quicksand APIs |
| 12:53 | <annevk> | JakeA: and also never paying off the technical debt they leave behind |
| 12:54 | <annevk> | (quicksand API is a thing I just made up btw, to give this a name) |
| 12:56 | <annevk> | JakeA: I guess if we already expose this to some extent we can at least ensure through tests things are consistent, but I'm not particularly pleased |
| 12:57 | <JakeA> | annevk: I'll see what I can do to properly plumb it through navigate |
| 12:57 | <annevk> | JakeA: also, given that you reduced the scope of the proposal I'm somewhat more comfortable with it |
| 12:58 | <annevk> | JakeA: should have read that comment first |
| 13:41 | <annevk> | JakeA: gave your comment a thumbs up, let me know if you need something more 😊 |
| 13:42 | <JakeA> | annevk: ta, will get some tests together than start looking at the specs. We have internal customers that are mostly interested in reload/history, but I don't want to count out needing to split out 'history' later. |
| 14:48 | <kochi> | annevk: just updated #w3c/webcomponents/713 |
| 14:48 | <kochi> | having tomdale@ is a good news |
| 14:49 | <annevk> | yeah is |
| 14:49 | <kochi> | if not Yehuda |
| 17:42 | <jugglinmike> | Hey jyasskin--are you still up to talk today? |
| 17:56 | <jyasskin> | jugglinmike: Agh, I have a meeting in 5 minutes, but I'll be free after 11:30 or so. I'll also read your bug. |
| 18:03 | <jugglinmike> | Thanks, jyasskin! |
| 19:00 | <jyasskin> | jugglinmike: Ok, I might have to disappear for a bit, but I've re-read https://github.com/w3c/permissions/pull/151 and can talk about it intelligibly. |
| 19:02 | <jugglinmike> | Got it, jyasskin |
| 19:03 | <jyasskin> | jugglinmike: I think your wording for "Interpret parameters.state as if it were the result of an invocation of permission state for typedDescriptor with the argument target made at this moment." is fine. I tried formalizing this state more in https://github.com/w3c/permissions/pull/96 (and #91 and #95), but folks didn't like it. |
| 19:03 | <jyasskin> | jugglinmike: re "WebDriver algorithms execute outside of any particular event loop", that's why you need to post to an event loop before modifying fields of a settings object. We don't want to modify those fields concurrently with algorithms using them. |
| 19:05 | <jyasskin> | jugglinmike: about the always-granted APIs like "midi", it's fine with me to let the UA reject the change at the beginning of Set Permission instead of the point where it actually tries to change the permission state. |
| 19:06 | <jyasskin> | jugglinmike: Did you have any other questions? |
| 19:06 | <jugglinmike> | jyasskin: I think so--in response to the feedback you're giving me now :) |
| 19:08 | <jugglinmike> | As far as formalizing state: I started down the road of defining a "permission cache" for each environment settings object. I think this is a primitize form of the patch you shared above, and if so, I would expect it to likewise meet resistance. https://github.com/w3c/permissions/compare/master...bocoup:cache |
| 19:09 | <jugglinmike> | I didn't got very far with that patch because I wanted to talk with you first. Does the above sound right to you? |
| 19:11 | <jugglinmike> | That patch would need to make "New information about the user's intent" into a formal algorithm, and the input would need to be well-defined (I think: a permission descriptor and an environment settings object) |
| 19:14 | <jyasskin> | Yeah, I tried hard to define that cache, and could never get agreement about it. That was complicated by some Mozilla folks being mad that permissions.request() was in the spec, and since it's gone, you might have better luck now, but it's not something I'm enthusiastic to try again |
| 19:15 | <jugglinmike> | Hmm, okay |
| 19:16 | <jugglinmike> | It's too bad your patch didn't go through, but I'm glad to hear that you were thinking along the same lines |
| 19:16 | <jyasskin> | I think you're right that the inputs are a permission descriptor and an environment settings object. |
| 19:16 | <jugglinmike> | I'll have to take some time to read the review you received for that patch |
| 19:17 | <jyasskin> | If you do want to try again, I think #91, #95, and #96 have the relevant people to talk to. |
| 19:17 | <jugglinmike> | because it seems to me like there already is a cache--it's just defined very informally |
| 19:18 | <jugglinmike> | and the way we're considering interacting with it in this WebDriver patch kind of forces that issue |
| 19:19 | <jugglinmike> | We're basically saying, "update the cache" but wording it in such a way that an implementor looking at one part of the spec would never suspect its usage in another |
| 19:19 | <jyasskin> | It's informal because it's slightly different for each browser. https://github.com/w3c/permissions/pull/151#discussion_r140614720 has a brief summary of how browsers differ here, and I think one of those PRs has my more detailed investigation. |
| 19:20 | <jugglinmike> | Oh, right. I was reading that in the context of "realms," but now I see that you were describing the caching mechanisms |
| 19:20 | <jyasskin> | WebDriver can (hopefully) set the browser to a "testing" mode that matches the "testing" mode of all other browsers, but, for example, Firefox's default mode never saves a permission response at all, which definitely doesn't work for the proactive model you're aiming at. |
| 19:23 | <jugglinmike> | What do you think about formalizing the informality? In other words, something like, "The user agent MAY cache requests to read the state for a given descriptor and environment settings object, but this cache must be invalidated by "Set Permission" |
| 19:24 | <jugglinmike> | with similar text accompanying the new WebDriver "Set Permission" command |
| 19:24 | <jyasskin> | This is a difference between your "cache" change and my attempts to define a "store". Are you thinking that an un-cached permission state gets fetched from the user? |
| 19:25 | <jyasskin> | Hm, no, because then "Set Permission" would be forcing something into the cache instead of invalidating the entry there... |
| 19:26 | <jugglinmike> | I think so, but I'm still hazy on the details. That's because I don't fully understand the text "and the UA has not received new information about the user's intent" |
| 19:27 | <jugglinmike> | That seems a little unbounded. Would it be fair to add "...about Permissions Descriptor |x| and environment settings object |y|" ? |
| 19:27 | <jyasskin> | Ah, yes, I think that won't break anything. |
| 19:28 | <jugglinmike> | Because trying to formalize the cache makes it seem like any "new information about the user's intent" would clear the entire cache |
| 19:29 | <jyasskin> | Mhmm. Now, a browser *is* free to treat the user clearing the geolocation permission on one tab as information about their intent for the notifications permission on another tab, or even another origin. |
| 19:30 | <jyasskin> | The note about implicit signals in https://w3c.github.io/permissions/#new-information-about-the-users-intent says to be cautious about that. |
| 19:32 | <jugglinmike> | Oh! I think I missed that since it landed since I started this patch. I ought to re-read the spec from top to bottom. Sorry about that |
| 19:32 | <jyasskin> | No worries. :) |
| 19:33 | <jugglinmike> | I may be over-thinking this now, but I'm starting to get confused about the difference between "the user's intent" and "the UA's interpretation of the user's intent" |
| 19:36 | <jugglinmike> | In the example you shared, it seems like you could argue that you've only received information about the user's intent for the geolocation permission. Though i wouldn't make that argument myself. |
| 19:37 | <jugglinmike> | So maybe that's too pedantic |
| 19:38 | <jyasskin> | :) Everything here is about the UA's interpretation of the user's intent. One particular example where that's important is when *other* users flag a site as spammy or hostile, Chrome wants to be able to revoke your grant of the permission, on the theory that you intend to avoid spammy or hostile sites but might not have realized when you granted this particular site permission. |
| 19:38 | <jyasskin> | (We don't do this today, unless something's changed, but it's something the permissions spec should allow in the future.) |
| 19:40 | <jyasskin> | jugglinmike: So, even when I was modeling this as a store, there was blanket permission for the browser to change the store at almost any time. |
| 19:47 | <jugglinmike> | sorry jyasskin, I dropped again. I've switched to a wired connection |
| 19:47 | <jyasskin> | jugglinmike: What's my last message you saw? |
| 19:47 | <jugglinmike> | > jugglinmike: So, even when I was modeling this as a store, there was blanket permission for the browser to change the store at almost any time. |
| 19:47 | <jyasskin> | That was my last message. :) |
| 19:48 | <jugglinmike> | great |
| 19:49 | <jugglinmike> | Your comment makes it sound like "forcing something into the cache" is a deal-breaker, but as I understand it, that is exactly what Set Permissions needs to be doing |
| 19:50 | <jugglinmike> | because when you say, "invalidating the entry there" as an alternative, I'm wondering what would happen if that was all that "Set Permission" could do |
| 19:52 | <jyasskin> | I think that your current wording in https://pr-preview.s3.amazonaws.com/bocoup/permissions/pull/151.html#set-permission-command should be implementable for all the browsers, and will in practice cause the automation to work when there's no human also poking at the browser to make it stop working. |
| 19:53 | <jugglinmike> | Okay, then maybe I should just drop it :) |
| 19:59 | <jyasskin> | jugglinmike: It's not that your concern is wrong: your text doesn't *require* the browser to do the right thing, and maybe someone will complain about it in the future. I just don't think it's worth spending a lot of time on it now. |
| 20:01 | <jugglinmike> | Understood. I appreciate your input--I'm in no position to prioritize things like this |
| 20:01 | <jyasskin> | I mean, I'm not really the final authority either, but if I were, your text would already be good enough. :) |
| 20:05 | <jugglinmike> | If only :P |
| 20:06 | <jyasskin> | jugglinmike: If I were to try to fix this, I'd probably try to nail down the "testing" mode, where the browser isn't allowed to take user input into account, and it always persists permissions, and then say that browsers only need to use that mode when WebDriver tells them to. But again, only if this matters to you or someone wants to veto the change without it, and you want to corral the Mozilla folks who objected |
| 20:06 | <jyasskin> | last time. |
| 20:06 | <jyasskin> | Ok, I'm running off to lunch. Let me know if any other questions come up. |
| 20:06 | <jugglinmike> | jyasskin: Could you give me a little guidance on how to allow the UA to reject requests? Should it be as specific as describing the case of setting an always-on permission to "denied" |
| 20:07 | <jugglinmike> | Or should it just say, "If the UA doesn't like the looks of the request, return a WebDriver error" |
| 20:07 | <jyasskin> | jugglinmike: I would probably use the second unless there's a reason to restrict UAs more than that. |
| 20:08 | <jugglinmike> | Okay then |
| 20:08 | <jyasskin> | There could be a note giving the example of denying always-on permissions, but I bet someone will come up with another time they can't munge the permission. |
| 20:08 | <jugglinmike> | So here's my plan for today |
| 20:11 | <jugglinmike> | 1- Extend the step "Interpret parameters.state as if it were the result of an invocation of permission state" to occur inside a task (and update the algorithm to wait for all such tasks to complete) 2- add a provision to allow the UA to initially reject the request if they can't honor it (for whatever reason) |
| 20:11 | <jugglinmike> | Does that sound right to you? |
| 20:12 | <jyasskin> | Yep, sounds great. |
| 20:12 | <jugglinmike> | Excellent |
| 20:12 | <jugglinmike> | Thanks for your time today, jyasskin |
| 20:12 | <jyasskin> | No problem. :) |
| 20:12 | <jugglinmike> | Have a good lunch! |
| 20:23 | <jsbell> | Thought I got pinged here but maybe not. Searching the logs, though... |
| 20:24 | <jsbell> | othermaciej: new TextDecoder('windows-949').encoding === "euc-kr" |
| 20:25 | <jsbell> | Not sure that was the question (from Nov 6th) though. :) |
| 20:26 | <jsbell> | You can also load a page w/ <meta charset=windows-949> and inspect its document.characterSet (again, not sure that was the question) |
| 20:27 | <othermaciej> | jsbell: I don't know what question that would be the answer to |
| 20:28 | <jsbell> | othermaciej: https://freenode.logbot.info/whatwg/20171106#c1367176 |
| 20:29 | <jsbell> | I have partial answers for some of the other encoding questions that came up in that discussion but it may all be moot now. Feel free to re-ask. |
| 23:15 | <TimothyGu> | Domenic: re the Object.prototype.toString issue, V8 has this API called v8::FunctionTemplate::SetClassName that defines the behavior: https://v8.paulfryzel.com/docs/master/classv8_1_1_function_template.html#a491e77dc7ceb5b0fe75880d11f2dbe9e |
| 23:16 | <TimothyGu> | I'm guessing Chrome's IDL class generator uses this function, which leads to the issue you filed |
| 23:17 | <TimothyGu> | but not only does it govern the toString behavior, the function also sets the "name" property of the constructor function |
| 23:19 | <TimothyGu> | which means that in short, it should be a V8 issue to make SetClassName() only change the name of the constructor function and not any toString behavior |
| 23:20 | <Domenic> | TimothyGu: nice detective work. Yeah, we'll see how they come down... I hope it gets straightened out. |
| 23:20 | <jsbell> | TimothyGu: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/V8DOMConfiguration.cpp?type=cs&q=V8DOMConfiguration.cpp&sq=package:chromium&l=727 might be informative (that's where it's used by the bindings code) |
| 23:21 | <TimothyGu> | jsbell: thanks for the link. I think the binding code looks right |
| 23:22 | <TimothyGu> | v8::FunctionTemplate::SetClassName() sets the internal class_name property in the FunctionTemplate, which is then used by FunctionTemplateInfo::GetOrCreateSharedFunctionInfo in https://cs.chromium.org/chromium/src/v8/src/objects.cc?type=cs&q=objects.cc&sq=package:chromium&l=1308 |
| 23:23 | <TimothyGu> | it uses it in two ways as I mentioned: 1. as the name of the function (https://cs.chromium.org/chromium/src/v8/src/objects.cc?type=cs&q=objects.cc&sq=package:chromium&l=1335) and as the [[Class]] internal slot (https://cs.chromium.org/chromium/src/v8/src/objects.cc?type=cs&q=objects.cc&sq=package:chromium&l=1342) |
| 23:25 | <TimothyGu> | then this [[Class]] internal slot gets picked up in the CodeStubAssembler::ClassOf() (https://cs.chromium.org/chromium/src/v8/src/code-stub-assembler.cc?type=cs&sq=package:chromium&l=9724), which is itself called by Object.prototype.toString (https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-object-gen.cc?type=cs&sq=package:chromium&l=355) |
| 23:25 | <TimothyGu> | thats about it |