| 02:48 | <cybai> | Domenic: would you think https://github.com/whatwg/html/issues/4356 is somehow related to the Focus meta-bug stuff š? |
| 02:49 | <Domenic> | cybai: I guess so, in that it'll be more obvious why browsers differ and are allowed to differ. It won't solve the interop problem though, unless miraculously all browsers decide to have the same focus model independent of OSes |
| 02:55 | <cybai> | Domenic: yeah! thanks! I was confused what a focusable area while I filed that issue. Happy to see that meta-bug :D About the interop problem, I see; it would be great if all browsers decide to have same focus model independent of OSes š |
| 03:28 | <domfarolino> | Anyone know if CSS images have a default referrer policy of no-referrer? Trying to see if this test is asserting correct behavior: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/http/tests/security/resources/referrer-policy-conflicting-policies.html |
| 05:06 | <annevk> | domfarolino: they donāt |
| 05:07 | <annevk> | domfarolino: but that seems to be testing something else |
| 05:09 | <domfarolino> | It seems that the document's referrer policy will be the empty string since it is unset, and https://www.w3.org/TR/referrer-policy/#referrer-policy-empty-string (the example) I think indicates that it should be treated as no-referrer-when-downgrade. |
| 05:09 | <domfarolino> | I guess I don't see why the request should have no referrer at all, hmm |
| 05:28 | <annevk> | domfarolino: the meta sets it to origin, but the fetch is cross-origin |
| 05:28 | <annevk> | domfarolino: Iām assuming the second bit btw |
| 05:29 | <annevk> | domfarolino: that the meta has taken effect assumes something about delivery of the document I think |
| 05:30 | <domfarolino> | annevk: Ok, I was assuming it hasn't taken effect at the time of image fetching, as per "Checks that an CSS image that was created before a referrer policy was set". I am not sure if the fetch is x-origin |
| 05:35 | <annevk> | domfarolino: oh hmm, perhaps localhost is special? |
| 05:35 | <domfarolino> | annevk: Ah, I found https://cs.chromium.org/chromium/src/third_party/blink/web_tests/http/tests/security/referrer-policy-conflicting-policies.html?g=0&l=5, which I guess explains things |
| 05:35 | <annevk> | domfarolino: anyway, the default is not no-referrer |
| 05:36 | <domfarolino> | I guess the page is loaded via https, but the image request is made to an insecure origin, and therefore no-referrer-when-downgrade kicks in and results in no-referrer |
| 05:38 | <annevk> | So it is cross-origin |
| 05:39 | <annevk> | Itās weird to me the meta can take no effect, CSS is parsed sync, but this means fetches also have to be prepared sync; maybe one day CSS will define thatā¦ |
| 05:39 | <domfarolino> | yes, but I think the value of, or even inclusion of the meta tag is irrelevant. i think what is being exercised is the "downgrade" part, where no referrer is included in requests from secure => non-secure |
| 05:40 | <domfarolino> | interesting |
| 06:36 | <domfarolino> | annevk: so do you think it is _defined_ that the documentās RP at the time of fetching the CSS image there is the default empty string, since meta hasnāt ātaken effectā yet? |
| 06:38 | <annevk> | domfarolino: time of fetching or creating the request for the fetch is not defined |
| 06:39 | <domfarolino> | annevk: Wow Iām surprised even creating the request is not defined |
| 06:39 | <domfarolino> | That seems..not great lol |
| 06:40 | <annevk> | CSSās interaction with non-CSS is shaky |
| 06:47 | <domfarolino> | I see |
| 06:57 | <annevk> | Domenic: I'm a little surprised https://github.com/whatwg/html/pull/4603 got landed as we still have the Streams/IDL issues, or will someone file follow-ups? |
| 08:07 | <annevk> | FYI: https://github.com/whatwg/sg/issues/90 |
| 10:54 | <howdoi> | const portal = document.createElement('portal'); |
| 10:54 | <howdoi> | portal.src = url; |
| 10:54 | <howdoi> | portal.activate(); |
| 10:54 | <howdoi> | ^ post this, if I need to navigate back to the parent page, what should I do? |
| 10:56 | <howdoi> | (might be a very silly question, but not able to find it in the explainer) |
| 10:57 | <oliverdunk> | I believe what you want is adoptPredecessor, defined on the portalactivate event. That returns a portal containing the website you came from. |
| 11:03 | <howdoi> | oliverdunk: neat, let me give it a shot, portalHost also would be useful? |
| 11:05 | <oliverdunk> | howdoi: Are you asking so you can communicate with it? I assume portalHost would become undefined on the context that's been activated, and become defined on the context you are coming from. |
| 11:06 | howdoi | oliverdunk: yes, first up trying to figure out the navigate back. (too much of a grey area) |
| 11:11 | <oliverdunk> | You'd want to listen to the portalactivate event, and when it fires, call adoptPredecessor on the event and store the returned element. When you're ready, you could then call activate on the element you're storing somewhere to go back. I'm not sure if you need to actually embed the portal for it to stay loaded. |
| 11:15 | <howdoi> | What I am trying to do is a SPA, with multiple portals and seamless navigation between them... |
| 11:19 | <oliverdunk> | That's definitely possible, is there something about my explanation that you're struggling to understand? Happy to elaborate. |
| 11:45 | <howdoi> | oliverdunk: thanks a ton, trying it now |
| 11:48 | <tobie> | Ms2ger I saw that you had PR Preview report an error to you recently. Was it helpful and did it let you fix the issue easily? |
| 11:49 | <tobie> | Ms2ger: what can be improved about it? |
| 11:49 | <Ms2ger> | I did? |
| 11:49 | <tobie> | Ms2ger: https://github.com/whatwg/html/pull/4603 |
| 11:50 | <tobie> | Ms2ger: if you look back at the edits to the OP |
| 11:51 | <Ms2ger> | I think that may have been in response to Domenic's edit |
| 11:52 | <tobie> | Ms2ger: oh! Well, Domenic if you have comments/suggestions, you're welcome. |
| 13:52 | <howdoi> | oliverdunk: still around? |
| 13:53 | <oliverdunk> | Indeed :) |
| 13:53 | <howdoi> | nice, just came across portal.replaceWith() |
| 13:56 | <oliverdunk> | That should work, although it's a ChildNode thing, rather than a portal thing: https://developer.mozilla.org/en-US/docs/Web/API/ChildNode/replaceWith |
| 13:57 | <howdoi> | oliverdunk: so here is what I understood: |
| 13:57 | <howdoi> | 0. Say, example.com, has a portal to example.xyz |
| 13:57 | <howdoi> | 1. On click of a button in example.com, we activate the portal. |
| 13:57 | <howdoi> | 2. If example.xyz I shall have portalactivate event and get ref to example.com from adoptPredecessor |
| 13:57 | <howdoi> | 3. Now I can navigate back to example.xyz on need. |
| 13:57 | <howdoi> | Correct me if I am wrong. |
| 13:58 | <oliverdunk> | Yep, exactly. The only caveat is that I think you need to insert the portal returned by adoptPredecessor into the DOM. I could be wrong, but I believe that if you don't, the portal will be closed. |
| 13:59 | howdoi | it's the same replaceWith, heh heh, forgot that portal is also an HTMLElement |
| 14:00 | <howdoi> | okies, trying to make two plain html pages and emulate this use case |
| 14:00 | <howdoi> | or rather post these two pages on two diff ports and test |
| 14:02 | <oliverdunk> | It sounds like what you've got should work, let me know if you have more questions. Off topic: closing a portal sounds really sci-fi and I love it. |
| 14:04 | <howdoi> | oliverdunk: holy goodness, I felt the same about portal closing! |
| 14:05 | <howdoi> | also, where I can read more about CORS, CSP and other security concerns for portal? |
| 14:11 | <oliverdunk> | I believe it's still up for debate, issues like https://github.com/WICG/portals/issues/17 and https://github.com/WICG/portals/issues/22 may be worth a read. The spec has an empty section for this at the moment: https://wicg.github.io/portals/#security-considerations |
| 14:14 | <howdoi> | hmm, interesting |
| 14:15 | <howdoi> | window.addEventListener('portalactivate', () => {}) is not getting trigged, but the portal is loading |
| 14:16 | <Domenic> | annevk: can I get a green check mark on the JSON parse PR? Will rebase and merge if so. |
| 14:16 | <annevk> | Domenic: ah yes, will do that |
| 14:16 | <oliverdunk> | howdoi: Looks good to me. You're aware that it only fires after the activate() call? |
| 14:18 | <howdoi> | oliverdunk: yes, but if page-1 is loading it via <portal src="domain/page2"/> is in't like activate? |
| 14:19 | <oliverdunk> | Nope, at that point all you've got is window.portalHost. activate means when the portal becomes full screen, takes over the address bar etc. |
| 14:22 | <howdoi> | but I don't see page-1 contents, I just see page-2 the contents when I load page-1 which has the portal element in it |
| 14:23 | <oliverdunk> | So you're embedding page2 into page1 as a portal the same size as the viewport? |
| 14:24 | <howdoi> | yup |
| 14:25 | <oliverdunk> | So the idea is that page1 is almost like an invisible host that just manages sending you between the pages? |
| 14:26 | <howdoi> | Finally, I would like to have multiple portals in page1, let me reduce the the viewport and see, I get the point |
| 14:28 | <howdoi> | Rather for now, let me have a button which on click loads the portal, there by invoking activate |
| 14:28 | <oliverdunk> | Is your goal multiple portals on page1 displayed in a grid? Or multiple full size portals with only one visible at a time? |
| 14:28 | <oliverdunk> | Or something else entirely :P |
| 14:29 | <howdoi> | I was trying to gauge the difference between explicit activate call vs <portal /> |
| 14:29 | <howdoi> | hah hah, grid of portals, that should go fullscreen on user actions |
| 14:34 | <howdoi> | Failed to execute 'activate' on 'HTMLPortalElement': The HTMLPortalElement is not associated with a portal context, what, but why? |
| 14:35 | <oliverdunk> | Is this going from page2 back to page1? It sounds like you the portal was closed because it wasn't added to the DOM. |
| 14:38 | <howdoi> | it wasn't added, right! |
| 14:39 | <howdoi> | now I am seeing an unexpectedly closed the connection. |
| 14:40 | <oliverdunk> | Where's that? |
| 14:40 | <howdoi> | localhost:3000 is the main page, localhost:3001 is the portal page; in the main page I have a button on click loads the portal |
| 14:42 | <oliverdunk> | howdoi: can you go through where exactly the error appears? Although it sounds like a server error rather than something wrong with your JavaScript. |
| 14:43 | <howdoi> | oliverdunk: both the main page and the portal page loads fine independently, from page one on button click I create a portal element, assign the src to the portal page, append it to the html and invoke activate; but after I click the button it loads a fullpage with an unexpectedly closed the connection. |
| 14:44 | <howdoi> | duh! my bad, `https` hmm |
| 14:45 | <howdoi> | https://usercontent.irccloud-cdn.com/file/kjLQUyRp/hmm%2C%20I%20had%20given%20it%20as%20https%3A%2F%2F%20instead%20of%20http%3A%2F%2F |
| 14:47 | <howdoi> | So, now on click the portal loads fullscreen, but portalactivate event is not getting triggered yet |
| 14:47 | <howdoi> | also, when the portal loads, devtools close |
| 14:51 | <oliverdunk> | I'm seeing the same, that looks like a bug. Not sure why the event isn't called. |
| 14:53 | <oliverdunk> | There's definitely a portalactivate event listener registered, and then you call activate()? |
| 14:56 | <howdoi> | oliverdunk: yes, should we report the devtool bug? {I am sure someone else would have} |
| 14:57 | <oliverdunk> | I couldn't see anything: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3ABlink%3EHTML%3EPortal+. I decided not to bother, as it'll almost definitely be picked up as they work on DevTools support - no harm in doing so if you want to, though. |
| 14:59 | <howdoi> | okies, for now focusing on get this thing done |
| 15:06 | <howdoi> | oliverdunk: the `portalactivate` not triggering could be a bug too? |
| 15:07 | <howdoi> | let me relaunch canary, I was on 76.0.3789.3 |
| 15:08 | <howdoi> | same |
| 15:08 | <oliverdunk> | It seems pretty fundamental to me and I'd be surprised if it wasn't spotted. I'm also not having any trouble on my end. Are you able to share your code? |
| 15:08 | <howdoi> | sure |
| 15:13 | <howdoi> | oliverdunk: https://gist.github.com/hemanth/ebb6a2e01f10c515162b4af7efd91474 format is screwed |
| 15:20 | <oliverdunk> | Huh. I guess portalactivate is being called before your event listener was registered. |
| 15:23 | <oliverdunk> | Not certain if that's something that should be fixed or not, probably worth making an issue for. In the meantime, you could add a delay - or for a more robust solution, have the second page post a message to the host when it's ready. |
| 15:28 | <howdoi> | `portalactivate` should be in portal page itself right? |
| 15:29 | <oliverdunk> | Yep. By issue I meant one on the spec by the way, rather than a chrome bug. |
| 15:37 | <howdoi> | oliverdunk: did we find a bug in spec!?! |
| 15:38 | <oliverdunk> | Bug is maybe pushing it, but a potential omission! It makes sense that the event is missed - but I can see other people doing what you've done, so perhaps the "default" behaviour of the browser should be overridden. Worth saying that I'm not involved in the spec at all - just a fan of portals like you. |
| 15:39 | <oliverdunk> | Did you want to open an issue? If not I'm happy to do so. |
| 15:44 | <howdoi> | oliverdunk: I am :) I just opened one with devtools |
| 15:48 | <howdoi> | oliverdunk: https://bugs.chromium.org/p/chromium/issues/detail?id=961740 I guess I am missing something trivial, but let us see |
| 15:53 | <oliverdunk> | I feel bad, but in looking for your first issue, I stumbled onto https://bugs.chromium.org/p/chromium/issues/detail?id=961142 - didn't think to look under DevTools . If you can you probably want to close yours as a duplicate. For the second it's probably better at https://github.com/WICG/portals/issues. Chrome's implementation is fine, the discussion to be had is about if the spec should have a special case for when the page hasn't |
| 15:53 | <oliverdunk> | loaded yet. |
| 16:15 | <smaug____> | Domenic: https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/scripting/processing-model-2/unhandled-promise-rejections/support/promise-rejection-events.js#L461 isn't quite right, I think |
| 16:16 | <smaug____> | postMessage and timers use different task sources, so any ordering between those can't be guaranteed |
| 16:16 | <Domenic> | Yeah, that makes sense. Can we find any DOM manipulation task source replacement for postMessageTask? |
| 16:17 | <smaug____> | let me try to find and fix the test (first in Gecko wpt) |
| 16:17 | <Domenic> | Thank you! |
| 16:18 | <howdoi> | oliverdunk: I got in touch with the spec authors let us see what they have to say, before we file an issue? |
| 16:19 | <oliverdunk> | Sure |
| 16:38 | <smaug____> | A simple DOM manipulation task source task: data:text/html,<script>var d = document.createElement("details"); d.ontoggle = function() { console.log("a task"); }; d.setAttribute("open", "");</script> |
| 16:38 | <smaug____> | hacky, but simple |
| 17:11 | <Domenic> | Perfect :) |
| 17:52 | <eeeps> | https://w3c.github.io/ServiceWorker/#cache-addAll Under the process the response substeps -- specifically the bit about Vary --I'm guessing that "If fieldValue matches '*'" means, match the literal string '*"? So addAll wont' cache anything that has "Vary: *"? (but it will cache for other, non-wildcard values of Vary?) |
| 19:42 | <eeeps> | [nvm], confirmed that it's screening out `Vary: *`, which apparently people use, as a form of cache control?? |