WHATWG
2023-05-11
plaintext logs
prev next
source on github
01:37
<jugglinmike>
Is toString intentionally omitted from the Location object's IDL? https://html.spec.whatwg.org/multipage/nav-history-apis.html
02:23
<jugglinmike>
Actually, since toString could alternatively be defined in the additional creation steps but is not, I ought to ask: can someone tell me where location.toString is defined? (Chrome and Firefox expose it as an "own" property. Unlike what's spec'd for location.valueOf, the value is distinct from the corresponding property on the Object prototype.)
02:55
<jugglinmike>
This was the central topic of this 2017 patch, but the resolution is confusing me. The change to the specification seems to rely on prototypal inheritance of Object.prototype.toString, but the corresponding tests added to WPT expect an "own" property.
05:26
<bakkot>

question:

how does that... work? is it implicitly "convert"ing strings to scalar strings? https://infra.spec.whatwg.org/#javascript-string-convert

assuming yes, in which case Chrome has a bug - import('./\ud800.js') doesn't actually end up triggering a network request for %EF%BF%BD.js”, which is what it would do if it did the specified conversion (FF and Safari do trigger that request)

05:31
<sideshowbarker>
TabAtkins: https://github.com/speced/bikeshed-boilerplate/pull/39 is a patch for making that change to fix the fragment-preserving redirect behavior for the CSS specs
07:19
<annevk>
snek: I'm gonna take over your WebSockets work, hope that's okay
07:22
<annevk>
bakkot: it's not, you found a bug, but Fx/Safari behave as the spec should read (it should call convert before it calls the URL parser)
13:43
<annevk>
smaug: did you follow the discussion in https://github.com/whatwg/dom/pull/1152? Are you still okay with the PR as-is?
13:43
<annevk>
smaug: I'm okay with it still I think, but I'd like at least one more set of eyes
14:20
<snek>
snek: I'm gonna take over your WebSockets work, hope that's okay
go for it fam
14:24
<annevk>
snek: shall I add you to the Acknowledgments section?
14:25
<snek>
oh you opened a whole separate pr
14:25
<snek>
yeah some form of attribution would be nice
14:28
<snek>
does your change make it so that the resulting .url will still be ws scheme?
14:29
<snek>
I'm not a huge fan but I'll take what I can get
14:34
<annevk>
snek: it does, I don't think it's worth supporting two sets of URLs (even though we later do rewrite back to HTTP(S)); it's unfortunate we added ws/wss, but they are what callers of .url expect
15:22
<Dominic Farolino>
Is there a way to click on a reference of a dfn in a spec, and immediately get a link to that reference? (Instead of having to go to the dfn, have the gray dfn box pop up, and binary search through it to find which reference I was at a second ago)
15:45
<zcorpan>
Dominic Farolino: inspect element, copy id
15:46
<Dominic Farolino>
Yikes! In at least the HTML Standard inspecting by element gives me a huge layout shift due to DevTools being popped
15:46
<zcorpan>
or select the link and click the file a bug link
15:47
<zcorpan>
Dominic Farolino: if you have devtools at the bottom there's no layout shift
15:47
<Dominic Farolino>
What do you mean by "select the link"? Click it? Highlight it?
15:47
<Dominic Farolino>
That's true
15:47
<zcorpan>
Highlight it
15:48
<smaug>
annevk: hmm, I had missed possible change to existing behavior
15:49
<smaug>
but I think the new behavior is better, if original is aborted first (in that fetch test)
15:49
<smaug>
so, I think the pr should be fine
16:06
<annevk>
smaug: thanks, checking with cdumez as well and then I guess I'll merge it tomorrow or early next week
17:06
<jub0bs>
Is there anyone from Mozilla around? I'd like to gain access to https://bugzilla.mozilla.org/show_bug.cgi?id=1790311 (which is referenced on https://www.mozilla.org/en-US/security/advisories/mfsa2022-47/#CVE-2022-45411). The bug could presumably be made public, at this stage.
17:07
<jub0bs>
annevk: Am I correct in assuming that CVE-2022-45411 is what prompted you to add X-HTTP-Method-Override and the other two as "conditional" forbidden request-header names? https://github.com/whatwg/fetch/pull/1541
17:08
<annevk>
jub0bs: I'm not familiar with specific CVE numbers
17:09
<annevk>
Oh, you linked something above. Seems likely?
17:22
<jub0bs>

Cross-Site Tracing occurs when a server will echo a request back via the Trace method, allowing an XSS attack to access to authorization headers and cookies inaccessible to JavaScript (such as cookies protected by HTTPOnly). To mitigate this attack, browsers placed limits on fetch() and XMLHttpRequest; however some webservers have implemented non-standard headers such as X-Http-Method-Override that override the HTTP method, and made this attack possible again. Firefox has applied the same mitigations to the use of this and similar headers.

17:23
<jub0bs>
annevk: It has to be related, but your PR (#1541) on the Fetch standard doesn't make explicit reference to this.
18:08
<annevk>
jub0bs: it's not something we keep track of when doing web standard security fixes
19:08
<TabAtkins>
sideshowbarker: Merged, sorry for the delay.