03:23 | <Domenic> | Ian Hickson: please fix live DOM viewer :). Or open source it somewhere so we can host our own. |
03:23 | <Domenic> | (Save button is broken.) |
07:07 | <freddy> | In the meantime, I like https://livedom.bentkowski.info/ a lot. It's got a "share URL" feature but that just throws the whole input into a URL parameter which might be a bit long and unwieldy |
07:16 | <annevk> | keithamus: I'm not sure I understand https://github.com/whatwg/fullscreen/issues/124#issuecomment-1738125683, but it also seems like something that is better raised with the CSS WG? |
07:18 | <keithamus> | Sure, I can raise it there. I was mostly +1ing and adding what I thought would be useful context. |
07:42 | <annevk> | johannhof: Noam Rosenthal: should Set-Cookie be honored on 101 (current answer is yes), 103 (current answer is no), and other 1xx responses (current answer is no)? I'll open an issue against Fetch for this because I don't think we have fully considered it. |
07:46 | <annevk> | https://github.com/whatwg/fetch/issues/1710 |
08:00 | <Noam Rosenthal> | annevk: I wonder how this is used in 101 for Websockets or whatnot... my immediate intuition would be that 1xx responses setting cookies would be a violation of them being "informational" |
08:01 | <annevk> | Noam Rosenthal: I see you are not familiar with our topic :p |
08:02 | <annevk> | More seriously, I'm not sure. I know there's at least a WebKit test for this. |
08:02 | <Noam Rosenthal> | annevk: you mean "leave your sense of logic out the door"? yes, familiar with it... hence "I wonder". I don't have a concrete input into this, let me do some research. |
08:04 | <annevk> | Noam Rosenthal: I also wonder what happens in practice for 103 today. Perhaps browsers match Fetch, but maybe only half of them do or some such. |
08:07 | <annevk> | Domenic: I thought we had resolved on https://github.com/whatwg/html/pull/9797 at some point. But maybe I'm missing something. smaug could you confirm/deny my assertions in that issue? |
08:24 | <sideshowbarker> | annevk: given that for 3xx response with no Location header but with a response body, the Fetch spec doesn’t explicitly prohibit UAs from processing the response body, and given that there’s also nothing in HTML that prohibits it either, I guess that means UAs can choose to do whichever they want with it (process it or not)? …and lacking any spec requirements around it, it’s not something that can be expected to necessarily behave interoperably? |
08:26 | <annevk> | sideshowbarker: no, then something would have to be explicitly indicated as implementation-defined |
08:26 | <annevk> | sideshowbarker: in this case the response would be returned to the caller as-is, so if you emit a 309 on the server, that's what the caller would see |
08:27 | <annevk> | sideshowbarker: that even holds when there is a Location header, as that's only defined to have meaning for a redirect response, which 309 is not |
08:27 | <sideshowbarker> | OK |
08:28 | <sideshowbarker> | well the specific context is https://bugs.webkit.org/show_bug.cgi?id=262030 and trying to decide how to resolve that |
08:30 | <annevk> | sideshowbarker: https://html.spec.whatwg.org/#default-fetch-and-process-the-linked-resource suggests that most link elements require an ok status, which means those would end up being rejected |
08:30 | <annevk> | sideshowbarker: stylesheet uses those default steps it seems |
08:33 | <sideshowbarker> | ah OK |
08:33 | <sideshowbarker> | thanks much |
08:37 | <sideshowbarker> | no existing tests for non-OK status in https://wpt.fyi/results/html/semantics/document-metadata/the-link-element, as far as I can see |
08:37 | <sideshowbarker> | …but there should be |
08:46 | <smaug> | annevk: I'm not sure that microtask issue has been discussed. Queuing a microtask without an event loop should be fine, since the one can find an event loop anyhow, but when queuing a microtasks, one needs to ensure there is a task in the loop (currently running task counts). |
08:47 | <smaug> | ...which is basically what you say in the initial comment 🙂 |
08:50 | <smaug> | I guess we need a concept of a current task? |
08:50 | <annevk> | smaug: Domenic seems to be saying that it's fine to add a microtask to an arbitrary event loop's microtask queue; I'm not quite able to articulate why that is wrong, but it seems quite wrong as you'd expect microtask order to be consistent within a single task and not have the outside world interfere |
08:50 | <annevk> | smaug: I guess it would violate run-to-completion in some way |
08:50 | <Noam Rosenthal> | Noam Rosenthal: I also wonder what happens in practice for 103 today. Perhaps browsers match Fetch, but maybe only half of them do or some such. Content-Security-Policy is read and respected, and only for the purpose of the early hint itself. But I'm pretty sure we don't test that all the rest are not respected. For Set-Cookie , I would expect it to be not respected at all or respected only for the early hint fetches themselves, but we never spec'ed the latterbashi |
08:50 | <smaug> | nothing would run the microtask |
08:51 | <smaug> | at least given how mictotasks should run |
08:51 | <annevk> | smaug: well in the spec the microtask queue is on the event loop so it would run in the next task or as part of some current task |
08:51 | <smaug> | or does something in the spec somehow trigger the event loop to run |
08:51 | <smaug> | exactly |
08:51 | <smaug> | the next task might never happen |
08:52 | <smaug> | there might not be such |
08:52 | <annevk> | Yeah that's a problem, but it also seems like a problem if it just executes as part of the current task (that might still be scheduling its own microtasks) |
08:53 | <smaug> | annevk: you mean in case of workers? |
08:53 | <annevk> | smaug: for instance, or a cross-site document |
08:53 | <smaug> | scheduling microtasks from outside just doesn't make sense |
08:54 | <annevk> | I mean apparently to some people it does, so we might need more than "just" :-) |
08:54 | <smaug> | well, one can't run microtasks without a task. Isn't that quite clear |
08:55 | <smaug> | so scheduling a microtask which might or might not run, depending on whether there are some other tasks around would be odd |
08:58 | <annevk> | smaug: aah, we have a currently running task on event loop, I can assert that's non-null |
08:58 | <smaug> | that sounds good |
08:59 | <smaug> | I wonder if web animations spec has a bug somewhere, if it doesn't guarantee that there is a task |
09:02 | <annevk> | smaug: I think there are quite a few specs that do this wrong, in part because of the promises guide which also did it wrong |
09:03 | <annevk> | smaug: they just resolve a promise from "in parallel" or some such and hope things work out |
09:03 | <smaug> | ah yes, easy to just resolve a promise at random point |
09:03 | <annevk> | Domenic: ^^ |
09:05 | <annevk> | Noam Rosenthal: makes sense. Thanks! I would expect Set-Cookie to work for the early hint preload fetches as those go through the 2xx and above pipeline. |
09:07 | <Noam Rosenthal> | annevk: I meant that I might expect the cookie from the 103's Set-Cookie to be sent to the early-hint fetch requests |
09:07 | <smaug> | I wonder if there should be some implicit task created, if there is no task around? Though, I guess that should be created always when resolving a promise in parallel. |
09:07 | <Noam Rosenthal> | ... but we didn't spec that |
09:10 | <annevk> | Noam Rosenthal: ooh I see |
09:13 | <annevk> | smaug: I think especially with in parallel you want to create a task as otherwise the microtask can end up in a random task; like if you do setTimeout and do some promise thingies in there, there shouldn't be microtasks in there from things that happened in other event loops |
09:13 | <annevk> | smaug: making it easier to resolve promises from in parallel though is something we could work on, although it's not that much work to queue a task |
09:14 | <smaug> | yeah, perhaps it is better to just require one to queue a task. That forces the spec author and also reader to think what actually happens. |
09:22 | <annevk> | And also to pick a task queue and such. |
10:46 | <annevk> | Domenic: when the navigation algorithm invokes "prepare to run script" the "currently running task" is non-null? |
10:46 | <annevk> | Domenic: I'll write a small PR for "prepare to run script" to illustrate |
12:18 | <annevk> | smaug: if you're around, has anyone from Gecko looked at fetchLater() ? |
12:19 | <annevk> | I could use some help getting https://github.com/whatwg/fetch/pull/1647 reviewed, don't think I'll get to it this week. |
12:20 | <smaug> | I was looking at it at some point, when it was still very unclear what was proposed |
12:20 | <smaug> | beacon or fetch later |
12:23 | <smaug> | hmm, I'm probably not super happy with "trigger when document is destroyed" |
12:30 | <smaug> | or perhaps that doesn't mean all the cases? |
12:30 | <smaug> | Like when OS kills a content process to reduce memory usage |
12:31 | <Noam Rosenthal> | smaug: the idea is to hint to the UA to perform this fetch as late as possible, or after a timeout |
12:32 | <Noam Rosenthal> | ... where the timeout is not a DOMTimer (it stays alive regardless of active/visible etc) |
12:33 | <Noam Rosenthal> | it's purposefully left a bit open how this is interpreted in terms of OS integration and situations like "kill due to low memory". |
12:37 | <annevk> | I have a Stack-Overflow-like question. What's a way to rewrite the following whereby "example.unlikely" as input doesn't result in a false-negative? I guess one could hash the input somehow, but that seems really gross?
|
12:40 | <Noam Rosenthal> |
? |
12:42 | <annevk> | Noam Rosenthal: yeah, I think this is another good reason for adding URLHost :-) cc Adam Rice |
12:50 | <smaug> | I wonder how different fetchLater then is vs pagehide + fetch/beacon. |
12:52 | <Noam Rosenthal> | smaug: it's a replacement for beacon. You can't fetch in pagehide because it would be aborted |
12:53 | <smaug> | and we need replacement for beacon because? |
12:54 | <Noam Rosenthal> | smaug: https://github.com/w3c/page-visibility/issues/59 |
12:54 | <smaug> | if pagehide has issues on mobile, doesn't this new thing have too |
12:55 | <Noam Rosenthal> | it doesn't! because you're not relying on JS running at a particular very late moment. |
12:56 | <Noam Rosenthal> | instead, you're saying at an earlier moment "please fetch as late as possible", instead of hoping that at that late moment you'll have JS execution |
12:56 | <smaug> | but you just said that OS killing the process in on purpose left a bit vague |
12:56 | <smaug> | so it is still unreliable |
12:57 | <Noam Rosenthal> | The idea is that that timeout is executed on the network process. however, the whole issue of "killing processes" is not entirely specified |
12:57 | <smaug> | (I'm not saying no to the API, just wondering if we're replacing some old unreliable APIs with a new unreliable API) |
12:58 | <Noam Rosenthal> | it leaves reliability to the browser rather than to the web developer. Of course that doesn't guarantee reliability if the implementation drops those fetches |
12:59 | <Noam Rosenthal> | if the OS kills the whole browser, for example, of course some of these will be dropped |
12:59 | <smaug> | right now the reliability of pagehide is also on the browser, not on the web developer |
13:03 | <Noam Rosenthal> | smaug: sure. this came as a shared design discussion between chromium & webkit folks, that making something declarative like this reliable is more feasible than reliably firing pagehide |
13:03 | <smaug> | I know |
13:03 | <smaug> | but it is still replacing one unreliable thing with another unreliable thing |
13:04 | <smaug> | which just feels a bit silly 🙂 even though it might be in practice good, since the new thing might less unreliable |
13:04 | <Noam Rosenthal> | Reliability is on a sliding scale I guess. |
13:04 | <Noam Rosenthal> | If we treated everything as 100% reliable or 100% unreliable we wouldn't get far. |
13:05 | <Noam Rosenthal> | we tried to design an API that gives the browsers a better opportunity at making these fetches reliable |
17:00 | <martin> | I find it a bit odd that when parsing HTML null characters are reported twice as errors. Once during tokenization and then again during tree construction. I'd consider the latter to be redundant. Does anybody have some insight/thoughts? |
17:22 | <Andreu Botella> | I find it a bit odd that when parsing HTML null characters are reported twice as errors. Once during tokenization and then again during tree construction. I'd consider the latter to be redundant. Does anybody have some insight/thoughts? � wouldn't be caught during tokenization? |
17:26 | <martin> | Good idea ... I also thought that ... but no, that is also caught during tokenization: it's a null-character-reference tokenizer error |
17:46 | <annevk> | martin: https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0063.html suggests it used to be different, might be worth looking at blame |
18:21 | <khafra> | does anyone know what part spec (webidl?) mentions if functions should be async/sync? ie:
thanks! |
18:23 | <annevk> | martin: hmm actually that part is still the same, so blame isn't needed |
18:39 | <Jeffrey Yasskin> |
Promise . Functions can also be async by taking a callback, but that's less common in newer APIs. |
18:45 | <Noam Rosenthal> | @khafra:matrix.org: not every function that returns a promise is an AsyncFunction . See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function |
18:50 | <Jeffrey Yasskin> | ... Not every async[hronous] function is an async function . |
18:53 | <Noam Rosenthal> | I could be wrong but I don't think there are WebIDL interfaces that have an AsyncFunction , mostly it's regular functions that return promises, like fetch .The AsyncFunction interface is usually for user code that's written in javascript and uses async/await internally rather than a web platform function.Note that a "special" thing about AsyncFunction is that it can't throw, only reject promises, and it always returns a unique promise. I guess some web APIs (perhaps even fetch() ) coincidentally has that guarantee without explicitly being an AsyncFunction . |
18:54 | <Andreu Botella> | all web APIs that return promises have that guarantee |
18:54 | <Andreu Botella> | WebIDL translates exceptions to promise rejections |
18:54 | <Noam Rosenthal> | do they have the other guarantee of always returning a unique promise reference? |
18:55 | <Andreu Botella> | I think so, but I'm not sure |
18:55 | <Noam Rosenthal> | well I guess that makes them implicitly an AsyncFunction , I don't recall if that interface has other special traits |
18:56 | <Jeffrey Yasskin> | It's provided by WebIDL, in https://webidl.spec.whatwg.org/#dfn-create-operation-function by "If op has a return type that is a promise type", and I guess by https://webidl.spec.whatwg.org/#es-promise. |
18:58 | <Andreu Botella> | from what I'm reading, it seems like as far as WebIDL is concerned, an API function could return an existing promise |
18:59 | <Andreu Botella> | I vaguely remember some discussion about that, wrt [SameObject] |
19:01 | <Jeffrey Yasskin> | [Edit: This statement is incorrect.] |
19:02 | <Andreu Botella> | that's when converting an ECMAScript value to a WebIDL Promise |
19:02 | <Andreu Botella> | not the other way around |
19:02 | <Jeffrey Yasskin> | Oops, thanks. |
20:38 | <bkardell> | annevk: in terms of the thing you reviewed with my heading-start -- was it from the other 2018 thread where you had build a pollyfill/proposal? aka https://github.com/whatwg/html/issues/83#issuecomment-369437548 ? |
20:42 | <bkardell> | I had a modified version of that polyfill that for the same reason, but yeah I guess that was a different base proposal anyway so I guess I should add an explanation. I hate polluting that issue with more tho, should I open a linked one as like "once we do the other one, then we should do this?" |