| 00:13 | <Krinkle> | interesting bug or feature: url(https:/w/skins/Vector/resources/skins.vector.styles/images/user-avatar.svg?b7f58) |
| 00:13 | <Krinkle> | apparently both Firefox and Chrome accept this |
| 00:13 | <Krinkle> | it's not quite a path url, nor is it a qualified url. it's got a protocol, and a full path, but no domain |
| 00:14 | <Krinkle> | and... it's taken to mean fill in the current domain |
| 00:44 | <Krinkle> | > new URL('https:/w/foo') |
| 00:44 | <Krinkle> | URL { host: "w", origin: "https://w";, protocol: "https", href: "https://w/foo"; } |
| 00:44 | <Krinkle> | seems to normalize as if there are two slashes, and treating first directory as domain |
| 00:45 | <Krinkle> | which isn't unreasonable either but not what browsers actually do it seems |
| 00:45 | <Krinkle> | at least, not in CSS url() context |
| 00:45 | <andreubotella> | Krinkle: what you're seeing in CSS url() is equivalent to new URL("https:/w/foo", "https://example.com";) |
| 00:45 | <Krinkle> | confirmed, Firefox also does this for <a href="https:/w/foo'"> goes to /w/foo |
| 00:46 | <Krinkle> | andreubotella: ooh, interesting! |
| 00:46 | <andreubotella> | https://url.spec.whatwg.org/#scheme-state, steps 6 and 7 |
| 00:46 | <Krinkle> | I didn't know that argument existed, but also - I wonder what quirk demands that the slash parsing itself varies based on there being a base |
| 00:47 | <andreubotella> | 2.6 and 2.7 I mean |
| 00:48 | <Krinkle> | right, so it specifically calls for this where having a base informs how this (arguably, error) scenario is handled. |
| 00:48 | <Krinkle> | if you go to Wikipedia now, and inspect the "person" icon at the top right, you'll find this (accidentally) in action. |
| 00:49 | <Krinkle> | slipped passed our QA and testing :) |
| 00:50 | <Krinkle> | Thanks for the spec lookup, appreciate it! |
| 00:50 | <andreubotella> | I can see how it would :) |
| 00:50 | <andreubotella> | I'm not sure what the reasoning was, try filing an issue |
| 00:52 | <Krinkle> | the case where there is a base URL, I think it's behaving quite reasonably. I mostly think of relative URls as filling in from the left, but sure why not fill in the middle. also web-compat probably makes it hard to break now e.g. if these mistakes exist in the wild. |
| 00:53 | <Krinkle> | for the base-less case, there might be an argument for it to throw or something, treating the first directory as the origin seems likely to mask mistakes and seems less likely to be intentional. But then again, it's very close to a real URL if you added just one more slash. |
| 00:53 | <Krinkle> | I can see how these two different worlds collided into a single spec :) |
| 00:54 | <Krinkle> | I don't know if we curerntly have a notion of "I want proper" and "I want whatever you can give me" as a distinction in the spec. E.g. one for resolving the address bar, and one for programmatic use of 'new URL' where you might want stricter |
| 00:55 | <andreubotella> | the URL parser doesn't throw, no matter how malformed the input |
| 00:55 | <Krinkle> | right, I see. ok, that seems reasonable then |
| 00:55 | <andreubotella> | and I suspect introducing something like that now for new URL would break sites |
| 00:55 | <Krinkle> | yeah |
| 00:56 | <Krinkle> | I've got a big backlog full of issues due to decodeURIComponent() sometimes throwing for malformed URIs |
| 00:56 | <Krinkle> | e.g. when people mess with percent encoding or some kind of script breaking a url. |
| 00:56 | <Krinkle> | instantly breaks out of deep code paths requiring local try-catch all over |
| 03:33 | <derpadmin> | what is the best way to send a notification that is compatible with a maximum of mobile devices? service worker? |
| 03:34 | <derpadmin> | Notification constructor did not work for me on chrome/samsung browsers on android |
| 03:35 | <derpadmin> | worked in firefox |
| 03:35 | <derpadmin> | and not IOS of course |
| 04:51 | <Krinkle> | https://whatwebcando.today/local-notifications.html |
| 04:51 | <Krinkle> | derpadmin: yeah, PWA and offline SW landed |
| 04:51 | <Krinkle> | But notifications and background sync not yet it seems |
| 04:52 | <derpadmin> | thanks Krinkle |
| 04:53 | <derpadmin> | I had a hard time wrapping my head around the 3 different way to do it |
| 04:53 | <derpadmin> | I succeeded but failed |
| 04:53 | <derpadmin> | failed on success as they say :) |
| 04:55 | <Krinkle> | Not even listed at WebKit status it seems :( - https://webkit.org/status/#?search=noti |
| 04:55 | <Krinkle> | Yeah.. |
| 05:09 | <derpadmin> | I have an error with the example |
| 05:09 | <derpadmin> | it is basically the same example I was reading on codelabs.developers.google.com |
| 05:10 | <derpadmin> | Service Worker registration error: TypeError: reg is undefined |
| 05:10 | <derpadmin> | trying to copy paste and try the code in another server now |
| 05:10 | <derpadmin> | as is |
| 05:40 | <derpadmin> | did you managed to made the example code you linked me run Krinkle ? |
| 05:40 | <Krinkle> | derpadmin: I have not, I didn't realize there was sample code there |
| 05:41 | <Krinkle> | probably not the best source for that sort of thing :) |
| 05:42 | <derpadmin> | well, it is pretty much the example floating around for service workers |
| 05:42 | <derpadmin> | ServiceWorkerRegistration.showNotification |
| 05:43 | <derpadmin> | trying with this syntax now |
| 09:09 | <benjamingr__> | > There is an XXX in the .webidl, since nullability of signal is unclear in the spec pr. |
| 09:09 | <benjamingr__> | smaug___ can you clarify that? I just used the same format `fetch` uses for the signal as prior art. I think it means the signal _may_ be null? I might be misunderstanding |
| 09:11 | <benjamingr__> | Discussion happened here: https://github.com/whatwg/dom/pull/919#discussion_r520717577 |
| 14:04 | <annevk> | benjamingr__: I think for fetch() it’s nullable so passing a Request works; might no longer be needed if we can make getters return undefined more easily, but doesn’t seem worth changing at this point… |
| 15:45 | <smaug____> | benjamingr__: I think the spec pr had a question about it |
| 15:46 | <smaug____> | so I'll tweak the Gecko patch once the spec has been updated |
| 15:47 | <smaug____> | (tweak it if needed) |
| 15:47 | <smaug____> | well, at least remove XXX comment if nothing else |
| 15:48 | <smaug____> | is there any use case for signal to be nullable? |
| 16:04 | <benjamingr__> | so n00b question: nullable means you don't have to pass it or you may pass literal `null`? |
| 16:06 | <smaug____> | nullable means that you can pass null |
| 16:52 | <annevk> | benjamingr__: optional is the default for dictionary members |
| 16:56 | <benjamingr__> | Oh then it probably shouldn't be nullable but it it should be optional |
| 19:12 | <smaug____> | it is optional by default |
| 19:12 | <smaug____> | non-optional would need 'required' |
| 19:30 | <benjamingr__> | OK, I think that's just a misunderstanding on my part - I'll fix it in the spec - should I also add a WPT to ensure passing `null` is not allowed? |
| 20:43 | <smaug____> | benjamingr__: that sounds reasonable |