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.
When we designed early hints we explicitly stated that only 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 latter
bashi
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?

function parseHost(input) {
  dummy = new URL("http://example.unlikely");
  dummy.host = input;
  if (dummy.host !== "example.unlikely")
    return dummy.host;
  return null;
}
12:40
<Noam Rosenthal>
function parseHost(input) {
  const false_host = `${uuid()}.unguessable`;
  dummy = new URL("http://${false_host}");
  dummy.host = input;
  if (dummy.host !== false_host)
    return dummy.host;
  return null;
}

?

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?
isn't that because &#0; 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:

const asyncFn = (async function() {}).constructor

fetch instanceof asyncFn // false

thanks!

18:23
<annevk>
martin: hmm actually that part is still the same, so blame isn't needed
18:39
<Jeffrey Yasskin>

does anyone know what part spec (webidl?) mentions if functions should be async/sync? ie:

const asyncFn = (async function() {}).constructor

fetch instanceof asyncFn // false

thanks!

Look at whether the function returns a 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.] You'll always get a new Promise from the platform function because even if the method steps return an existing one, it'll get converted to an ECMAScript value, which passes it through NewPromiseCapability(%Promise%).Resolve().
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?"