| 00:03 | <nox> | Domenic: At least Servo and Gecko have [Foo = "bar"] custom IDL attributes. |
| 00:03 | <nox> | Don't know about other vendors, but at least for those it wouldn't be a problem extending WebIDL right now. |
| 00:08 | <KiChjang> | huh, this looks like a positive change |
| 00:08 | <KiChjang> | i've encountered this footgun before |
| 00:08 | <KiChjang> | where the content attribute != the webidl attribute |
| 00:09 | <nox> | That's still true though. |
| 00:17 | <KiChjang> | albeit it's surfaced up at the webidl level |
| 00:17 | <KiChjang> | instead of being hidden in the HTML spec somewhere |
| 00:59 | <GPHemsley> | so this is fun... apparently a lot of animated GIFs are missing the block terminator byte of the Application Extension Block |
| 00:59 | <GPHemsley> | presumably because the spec forgets to define its contents (despite mentioning that the byte exists) |
| 01:03 | <GPHemsley> | ...that can't be right |
| 03:49 | <jolvera> | i've read the figure element description, but it's not clear if it's correct to use a <figure><img> inside an index of posts |
| 03:49 | <jolvera> | since the image is self-contained in it's own list of articles |
| 03:49 | <jolvera> | since the image is self-contained on each item from the list of articles* |
| 03:50 | <jolvera> | e.g., https://cl.ly/1i2T0y2X2Y0e |
| 03:51 | <jolvera> | what would be better, figure>img or aside>img ? |
| 04:55 | <Domenic> | jolvera: Those don't look like figures to me; nothing else in the document references them by saying e.g. figure 1.2 |
| 04:56 | <jolvera> | oh, makes sense, thanks! |
| 05:25 | <GPHemsley> | hmm... it seems perhaps I have been misinterpreting the GIF spec when it comes to block terminators... |
| 13:38 | <JakeA> | annevk: If data is to be persisted across browser restarts, the correct way to do this is to associate it with a https://storage.spec.whatwg.org/#bucket, right? As in, we should attach both service worker registrations and cache storages off buckets. |
| 13:41 | <annevk> | JakeA: yeah, I haven't really defined a hook for it as I don't know what it should look like |
| 13:41 | <annevk> | JakeA: but that's exactly the kind of thing we need to be doing across quite a few specs to make sure Clear-Site-Data and storage.clear() end up being well-defined |
| 13:44 | <JakeA> | annevk: and persistence, yeah. I guess "A bucket has an associated cache storage" is good enough. |
| 13:45 | <annevk> | JakeA: I guess the question is whether you need any kind of cleanup hooks |
| 13:45 | <annevk> | JakeA: I think IDB does |
| 13:45 | <annevk> | JakeA: so we might want something where you reserve space with some "spec callbacks" that get invoked as things happen |
| 13:46 | <JakeA> | annevk: Yeah. "Add the following steps to bucket's cleanup steps:". Dunno if we need them for service worker or the cache api. |
| 13:47 | <JakeA> | I guess the problem with that is the order of callback steps isn't clear, should it ever become observable |
| 13:47 | <annevk> | JakeA: the other slight problem with "y has an associated x" is that clearing y doesn't mean x is gone |
| 13:47 | <annevk> | JakeA: it's probably clear enough and certainly better than what we have, but doesn't quite feel proper yet |
| 13:48 | <JakeA> | annevk: wouldn't GC rules apply here? If the bucket is gone, and there are no JS references remaining, the underlying data can no longer be accessed. |
| 13:49 | <annevk> | JakeA: I guess that depends on whether the bucket is replaced or emptied |
| 13:50 | <annevk> | JakeA: if we define clear() as replacing that would indeed be fine |
| 13:50 | <JakeA> | annevk: ah I assumed it was replacing. Gotcha. |
| 13:51 | <annevk> | JakeA: currently https://w3c.github.io/webappsec-clear-site-data/ doesn't mention buckets at all, so I guess it can go either way |
| 14:00 | <annevk> | JakeA: updated https://github.com/whatwg/storage/issues/18 with this conversation |
| 14:01 | <JakeA> | annevk: bleh, sorry for missing that issue way back. (Going to review https://github.com/whatwg/fetch/issues/631#issuecomment-344583026 today) |
| 14:02 | <annevk> | JakeA: don't worry, I would have bothered you more if it was high priority |
| 14:52 | <wanderview> | JakeA: in regards to GC semantics... i think some operations are more immediate... like the user purposefully deleting storage for an origin (even if that site is open at the moment) |
| 14:53 | <annevk> | wanderview: I think from a theoretical perspective that could still be modeled as GC though |
| 14:54 | <wanderview> | annevk: we disconnect Cache objects even if referenced by js and they start rejecting if the user does that |
| 14:55 | <annevk> | wanderview: same for service worker registrations? |
| 14:55 | <wanderview> | annevk: we are not as good about those, but yes, we should be treating them as quota storage and purge atomically with Cache/IDB/etc |
| 14:56 | <annevk> | wanderview: but there you cannot observe a clear operation? |
| 14:56 | <wanderview> | annevk: we've gotten some privacy related bugs from people reporting this stuff still exists after they click the "clear storage" button, so we are trying to be more aggressive about it |
| 14:57 | <wanderview> | annevk: honestly I'm not sure what we do in that case... if a page is controlled by a service worker when the service worker is purged by the user... maybe we should make it uncontrolled... right now I think we leave it controlled and it ends up reinstalling its scripts right away |
| 14:57 | <annevk> | wanderview: oh |
| 14:58 | <annevk> | I guess this does argue for making it explicit how clearance is handled |
| 14:58 | <wanderview> | a user purge should probably be more immediate than a normal unregister() call, IMO |
| 14:58 | <annevk> | wanderview: it's not just user, soon it's also receiving an HTTP header or invoking storage.clear() |
| 14:58 | <wanderview> | I think maybe we changed our storage purge stuff recently to do an unregister() and then wait until the SW leaves to declare itself complete... that can delay the purge a long time |
| 14:58 | <annevk> | wanderview: ideally those all use the same path |
| 14:59 | <wanderview> | header yes |
| 14:59 | <wanderview> | not sure about storage.clear() when it comes to service workers |
| 14:59 | <wanderview> | but I am just getting my first cup of coffee.. |
| 15:00 | <annevk> | wanderview: I guess the privacy related bugs are worth calling out in a section, but if they don't touch upon observable behavior from sites it's less important that the spec covers that in detail I think |
| 15:01 | <wanderview> | annevk: conceivably we could have UX that says "you are clearing storage for these sites, we need to close these windows to perform this operation"... |
| 15:02 | <annevk> | wanderview: I think Clear-Site-Data does have something like refresh associated with it |
| 15:02 | <annevk> | wanderview: that's probably what you need with service worker registrations to properly do it |
| 15:03 | <wanderview> | that would be interetsing... if we had that for Clear-Site-Data then we could just reuse it for the browser UX to manually clear storage |
| 15:16 | <Domenic> | Re: https://github.com/w3c/web-platform-tests/issues/8308#issuecomment-345680118, I'd be amused to see a setup that communicated test results back from a paint worklet via the pixel patterns of some element. |
| 15:21 | <annevk> | Domenic: how do you read those pixels? |
| 15:22 | <Domenic> | Hmm. There must be some way to get them onto a canvas. |
| 15:22 | <Domenic> | Or, reftests! |
| 15:22 | <annevk> | That you could do |
| 15:22 | <annevk> | Clever |
| 15:23 | <jgraham> | I see a test api for getting an element onto a canvas in out future |
| 15:23 | <jgraham> | *our |
| 15:59 | <annevk> | jgraham: it’s been proposed various times, but SOP makes it painful |
| 15:59 | <jgraham> | annevk: Emphasis on *test* API |
| 16:00 | <annevk> | jgraham: ah doh |
| 16:01 | <jgraham> | Like this is a pretty straightforward addition to testdriver.js modulo usual concerns about pages with multiple windows/frames |
| 16:01 | <jgraham> | (which are basically: the webdriver story for interacting with multiple windows/frames is pretty broken) |
| 16:01 | <jgraham> | gsnedders: ^ |
| 16:02 | <jgraham> | Making people write reftests to test js apis inside paint worklets seems pretty broken, so if people are doing that we should fix this sooner rather than later |
| 16:09 | <annevk> | jgraham: I'm actually not sure what the testing plan for paint worklets is |
| 16:09 | <annevk> | jgraham: this discussion was mostly about testing test262 in agents, for which this is not a priority |
| 16:12 | <jgraham> | OK |
| 16:12 | <jgraham> | Still, don't tell people to write reftests to do that, let's fix it to work better before then |
| 16:15 | <annevk> | jgraham: okay, are we at the point where we can get cross-browser privileged APIs? |
| 16:16 | <annevk> | jgraham: if that was discussed at TPAC that sounds great, since it's been somewhat of a blocker for lots of types of tests |
| 16:16 | <jgraham> | annevk: At the moment we can iff the API is exposed in WebDriver or there's a defined test API (of course) |
| 16:17 | <jgraham> | So far I think priviledged click (same document only) works and key input is going to be added soon |
| 16:36 | <annevk> | JakeA: I think I responded to quickly to your parallel queue issue; after more consideration it makes sense as an extension of a parallel queue |
| 16:37 | <JakeA> | annevk: I've used somewhat hacky wordings to 'wait' for multiple parallel things to complete before. Your proposal would work there too |
| 16:37 | <JakeA> | annevk: eg step 7 https://wicg.github.io/background-fetch/#attempt-a-background-fetch |
| 16:38 | <annevk> | JakeA: when you just go in parallel, do several things in parallel, and then continue? Fair enough |
| 16:38 | <JakeA> | annevk: in that linked case, I want an early exit if one fails, which would be harder. Maybe waiting for a value isn't as hacky as I think. |
| 16:39 | <annevk> | JakeA: I'm thinking a counter would probably work |
| 16:39 | <annevk> | JakeA: increment when you see a shared thing, decrement when it's done |
| 16:39 | <annevk> | JakeA: when you dequeue a non-shared thing wait for the counter to hit 0 |
| 16:40 | <annevk> | JakeA: hmm, but then not tied to a parallel queue |
| 16:40 | <JakeA> | annevk: maybe it doesn't need to be. But I'd need aborting for the linked case. But maybe the linked case is already doing it well enough |
| 16:40 | <JakeA> | it is using a counter |
| 16:50 | <wanderview> | JakeA: thanks for the WPT test case review! |
| 16:55 | <annevk> | JakeA: if you decrement when you abort seems okay |
| 16:56 | <JakeA> | annevk: decrement by whatever it currently equals? |
| 16:56 | <JakeA> | wanderview: no problem! |
| 16:56 | <annevk> | JakeA: oh, I was thinking for each you abort you decrement by 1 |
| 16:57 | <annevk> | JakeA: maybe something like what you have is fine |
| 16:58 | <annevk> | JakeA: it seems a bit similar to spec-level promises in a way, so you might want .all or .any semantics |
| 17:02 | <wanderview> | JakeA: what do you mean by "Eventually I'd like to get rid of the "job" concept entirely, and replace it with appending steps to the appropriate parallel queue." |
| 17:02 | <JakeA> | annevk: yeah, .all is the behaviour I'm looking for here. Maybe this is separate to the parallel queue "shared" thing. |
| 17:04 | <JakeA> | wanderview: I find the whole 'job' thing a bit weird, since it contains arguments and the name of the thing to do. I'd rather there was a single parallel queue for all the things that must happen in sequence, and algorithms are just called with arguments within that queue |
| 17:05 | <wanderview> | JakeA: hmm... I guess I find the job concept easy to reason about and we've aligned our implementation with it conceptually |
| 17:06 | <wanderview> | but maybe what you are thinking would fit easily too... not sure... I just worry about accidentally allowing async operations to overlap by accident, etc |
| 17:06 | <wanderview> | the job stuff prevents that |
| 17:06 | <wanderview> | and we spent a long time getting that right |
| 17:11 | <annevk> | wanderview: parallel queue prevents that too and is grounded in the "in parallel" primitive |
| 17:12 | <annevk> | wanderview: having said that, I haven't studied jobs so maybe they fulfill the same criteria |
| 17:12 | <JakeA> | wanderview: the switch to parallel queues shouldn't involve any behaviour change |
| 17:13 | <JakeA> | annevk: wanderview: there's some brokenness in the spec today which is being fixed by adding parallel queues https://github.com/w3c/ServiceWorker/pull/1229 |
| 17:21 | <annevk> | \o/ |
| 17:28 | <wanderview> | JakeA: right now we allow the next job to run in the middle of an algorithm by resolving a promise... its unclear to me how that will be done with parallel queues based on non-overlapping algorithms |
| 17:28 | <wanderview> | anyway, I have to run out for a bit... |
| 17:41 | <JakeA> | wanderview: I guess I need to take a closer look at that bit |
| 17:43 | <annevk> | That sounds like shared steps |
| 17:43 | <annevk> | Hmm |
| 17:46 | <wanderview> | JakeA: annevk: I'm thinking of step 6 in the Install algorithm: https://w3c.github.io/ServiceWorker/#install |
| 18:34 | <JakeA> | wanderview: you can still bail out of queued parallel steps by going parallel again (or queuing a task if that makes more sense). But not sure if that solves this case. |
| 18:54 | <annevk> | I was thinking that too, sounds like something that does something synchronous, then does in parallel |
| 19:14 | <annevk> | I like how Barack Obama is seemingly aware of all the great memes about him and Joe Biden: https://twitter.com/BarackObama/status/932685522820042754 |
| 19:26 | <GPHemsley> | oh cool, the XMP extension to GIF totally ignores the way GIF stores data and then adds a hack at the end to get the parser back on track |