| 07:18 | <annevk> | ecobos: I think we need to fix the standard on non-fetch schemes and ideally prevent the fingerprinting angles |
| 07:19 | <ecobos> | annevk: I'm extremely confused about both our old and our less-old behavior in that case |
| 07:19 | <ecobos> | annevk: So this testcase: |
| 07:20 | <ecobos> | ``` |
| 07:20 | <ecobos> | <!doctype html> |
| 07:20 | <ecobos> | <iframe id="myframe"></iframe> |
| 07:20 | <ecobos> | <pre id="log"></pre> |
| 07:20 | <ecobos> | <script> |
| 07:20 | <ecobos> | onload = function() { |
| 07:20 | <ecobos> | let iframe = document.querySelector("iframe"); |
| 07:20 | <ecobos> | let log = document.getElementById("log"); |
| 07:20 | <ecobos> | let ex = null; |
| 07:20 | <ecobos> | try { |
| 07:20 | <ecobos> | iframe.contentWindow.location.href = "very-unlikely-to-exist:foo"; |
| 07:20 | <ecobos> | } catch (e) { |
| 07:20 | <ecobos> | err |
| 07:21 | <ecobos> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7867 |
| 07:21 | <ecobos> | annevk: anyhow that test-case, before firefox 64 used to _both_ navigate and throw |
| 07:22 | <ecobos> | annevk: that's so bonkers. We added a hack to not throw only for unknown protocol, which is terrible, https://bugzilla.mozilla.org/show_bug.cgi?id=680300. That didn't fix the underlying issue at all |
| 07:23 | <ecobos> | annevk: and then at some later point we apparently fixed the underlying issue that was throwing for all those errors |
| 07:23 | <ecobos> | annevk: but during all this time this has been detectable |
| 07:23 | <ecobos> | annevk: by just trying to poke at the error page loaded at the frame |
| 07:23 | <ecobos> | annevk: so... lol? |
| 07:25 | ecobos | shrugs, rips off the hack, will file a bug for actual mitigations for this |
| 14:12 | <annevk> | ecobos: ugh, I prolly dropped the ball on this at some point; throwing while still navigating is definitely bad news |
| 14:15 | <nox> | The real question is why are you talking about specs on a Sunday. |
| 14:16 | <annevk> | nox: it’s Sunday? Thanks for the heads up. |
| 14:50 | <nox> | Hah. |
| 17:49 | <Krinkle> | Hm.. It appears column-width is forcing children to be limited by the column width (and leading to overflow). I had always imagined it would go as narrow as the child allows somehow, so that if in one cirumstance, the contents are too wide, there would be fewer columns. But I"m seeing that Firefox, Safari, and Chromium all behave this way, E.g. at https://www.mediawiki.org/wiki/Category:Resource_loader_variables |
| 17:49 | <Krinkle> | https://usercontent.irccloud-cdn.com/file/dsjFpIFu/column-width%20problems.png |
| 17:49 | <Krinkle> | I imagine there's a way to loosen that up, but not seeing it.. |
| 17:53 | <Krinkle> | I guess conceptually it's not very different from if a device were as narrow as the column width, and I'd need to handle that too, so I guess word-break is the only available option here. That works :) |
| 17:54 | <Krinkle> | or rather, overflow-wrap: break-word, in this case. |
| 18:11 | <TabAtkins> | Krinkle: Hmm, `column-width: max(33%, min-content);` should work, I think. But yeah, you'll need to handle overflowing items on narrow viewports anyway, so might as well do that *too*. |
| 18:53 | <Krinkle> | TabAtkins: interesting. min-content is something I can specify in column-width on a parent like <ul> and will be applied in context of each <li> element? |
| 18:53 | <Krinkle> | I assumed 33% etc would be in relation to the <ul> itself. |
| 18:53 | <TabAtkins> | The ul's min-content size involves asking its children for their min-content size. |
| 18:54 | <TabAtkins> | https://drafts.csswg.org/css-sizing/#column-sizing |
| 18:55 | <TabAtkins> | (No *guarantees* on this working, btw; it's combining two newish things. Precede it with a `column-width: 33%;` in case it fails to parse.) |
| 18:55 | <Krinkle> | Oh I see. min-content is a special value specific to column-width |
| 18:55 | <Krinkle> | I assumed it was a generic width/height value as that would mean each column gets the width of the total of all children which is not what I want indeed. |
| 18:55 | <Krinkle> | Firefox says the syntax is invalid |
| 18:56 | <TabAtkins> | Yeah, when used on column-width it does "what you'd expect" and asks the children. If used on the ul it'll ask the children, then multiply it by the # of columns. |
| 18:56 | <TabAtkins> | "on the ul" I mean on the ul's `width`. |
| 18:56 | <Krinkle> | neat |
| 18:57 | <Krinkle> | Chromium rejects it as well. |
| 18:57 | <Krinkle> | and Safari too. |
| 18:57 | <Krinkle> | I guess very new then :) |
| 18:58 | <Krinkle> | or priority victim by vendors |
| 18:59 | <TabAtkins> | I don't think max() is in any public builds yet; it should be in the dev or beta channels for Safari, Chrome, and Firefox. |
| 18:59 | <TabAtkins> | Dunno about column-width:max-content |
| 19:00 | <TabAtkins> | ...oh wait, i'm dumb, there's no way that max-content would work, since we don't allow keywords in calculations yet. |
| 19:00 | <TabAtkins> | NEVER MIND |
