- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Apr 2021 16:00:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Auto-resize iframes based on content`.
<details><summary>The full IRC log of that discussion</summary>
<astearns> topic: [css-sizing] Auto-resize iframes based on content<br>
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1771<br>
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/1771<br>
<fantasai> TabAtkins: Fairly old issue, #1171<br>
<fantasai> TabAtkins: originated in HTML in the form of 'seamless' attribute on iframes<br>
<fantasai> TabAtkins: meant to allow isolating parts of a page, but still lay them out as if in the page<br>
<fantasai> TabAtkins: there were a bunch of issues, dropped from HTML<br>
<fantasai> TabAtkins: core ideas still requested by people, in various variants<br>
<fantasai> TabAtkins: We believe there's a useful and safe set of resizing behavior that we could expose now<br>
<fantasai> TabAtkins: that would solve some of the use cases<br>
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925<br>
<fantasai> TabAtkins: Core idea is that just the resizing portion of seamless is value<br>
<fantasai> TabAtkins: But security issues around being able to tell the size of 3rd-party content<br>
<fantasai> TabAtkins: bare minimum, different sizes of content depending on logged in or not<br>
<fantasai> TabAtkins: So should only be allowed to take size of 3rd-party content if it wants to allow that<br>
<fantasai> TabAtkins: Another problem, if 3rd-party page can trigger resizing without consent of containing page, can create problems as well<br>
<fantasai> TabAtkins: So 2-way agreement on sizing<br>
<fantasai> TabAtkins: First, outer page needs to opt into resizing based on iframe content<br>
<fantasai> TabAtkins: Suggestion is to use new 'resize' value in 'allow' attribute<br>
<fantasai> TabAtkins: Then for 3rd-party content, there's a window.resizeTo() method which is a no-op in iframes<br>
<fantasai> TabAtkins: Inner page can request such sizes<br>
<fantasai> TabAtkins: using this API<br>
<fantasai> TabAtkins: Whenever inner page wants a resize, triggers an event on iframe which bubbles up<br>
<fantasai> TabAtkins: if not prevetnDefault, then the iframe changes it's size<br>
<fantasai> TabAtkins: if cancelled, doesn't change size<br>
<fantasai> TabAtkins: This allows control over layout behavior across the page<br>
<fantasai> astearns: Possible scripts using resizeTo() and relying on the fact that it does nothing?<br>
<fantasai> TabAtkins: it's a no-op currently, so don't think so<br>
<fantasai> TabAtkins: ... [ missed ]<br>
<fantasai> astearns: Making page decide to allow event or not, already in place due to opt-in to resize behavior<br>
<fantasai> cbiesinger: Nothing sounds like CSS thing<br>
<fantasai> TabAtkins: kinda sorta<br>
<florian> q+ to ask at which level of sizing this works. natural size of the iframe? something else?<br>
<fantasai> TabAtkins: it's a cross-spec thing, does interact with CSS by adjusting intrinsic size of iframe<br>
<gregwhitworth> q+<br>
<fantasai> TabAtkins: gets into issue of same-origin content<br>
<TabAtkins> fantasai: YOu wanted a 2-way handshake for security<br>
<TabAtkins> fantasai: resizeTo() gives you 2-way for page consenting<br>
<TabAtkins> fantasai: If that page is already firing resizeTo() and expecting it not to ahve sec implications<br>
<TabAtkins> fantasai: I don't think paying attention to resizeTo() would break the framed page...<br>
<TabAtkins> fantasai: But if they're asking for it and it's currently not changing size, the outer page probably isn't expecting a problem.<br>
<gregwhitworth> q--<br>
<gregwhitworth> ack gregwhitworth<br>
<TabAtkins> fantasai: [clarifying] the issue isn't an attack due to sizing, it's a possibly unexpected info leak from the frame'd page, leaking the size it wants to size to<br>
<astearns> ack fantasai<br>
<fantasai> florian: currently, calling resizeTo() doesn't leak information<br>
<fantasai> TabAtkins: could check if stuff in iframes do this currently...<br>
<fantasai> fremy: It's not about stuff currently in iframes, but a page could put *anything* into an iframe<br>
<fantasai> fremy: which would leak information from that page, which was not intended to be in an iframe<br>
<fantasai> florian: resizeTo() doesn't have an effect on pages that are loaded into a window with multiple tabs<br>
<fantasai> florian: for exactly this reason: it would leak information about that page to other pages in the same window<br>
<astearns> ack florian<br>
<Zakim> florian, you wanted to ask at which level of sizing this works. natural size of the iframe? something else?<br>
<fantasai> florian: opening up this leak through iframes is similarly bad (worse maybe)<br>
<iank_> another path would be an additional dictionary argument to resizeTo, e.g. window.resizeTo(100, 100, {something: true});<br>
<fantasai> TabAtkins: Yeah, OK, we need to think about that more. Maybe needs a new API<br>
<fantasai> +1 iank_<br>
<fantasai> florian: In the case where resize does work, thing it affects is the natural size, right?<br>
<fantasai> TabAtkins: Yes. Right now iframes have natural size of 300x150, and this would change that<br>
<fantasai> TabAtkins: totally controllable, it's the weakest size input possible<br>
<fantasai> fremy: [missed]<br>
<fantasai> TabAtkins: currently iframes do not have an aspect ratio<br>
<fantasai> TabAtkins: Ability to infer an aspect ratio is an interesting possibility<br>
<jensimmo_> q+<br>
<fantasai> florian: As long as we're there, should we specify min size and max size separately<br>
<fremy> s/[missed]/do iframes have an aspect-ratio applied to that intrinsic size?<br>
<fantasai> TabAtkins: Interesting. Not unreasonable to consider.<br>
<emilio> q+<br>
<astearns> ack jensimmo_<br>
<fremy> q+<br>
<fantasai> jensimmo_: Curious about use cases<br>
<fantasai> jensimmo_: All I can think of is what ad networks will do, and I don't like those thoughts.<br>
<fantasai> TabAtkins: There's another proposal for 1st-party content, which addresses more use cases<br>
<fantasai> TabAtkins: but even within 3rd-party stuff, currently they do this resizing already, just with postMessage back and forth<br>
<fantasai> TabAtkins: This would standardize that<br>
<fantasai> TabAtkins: There's also things like Disqus, which does such special-case postMessage things<br>
<fantasai> TabAtkins: which is complicated and no standardized way to handle across multiple systems<br>
<smfr> q+<br>
<fantasai> TabAtkins: YouTube player, e.g., might want to do this. CodePen might want to ask for sizes on its examples. Anything that wants to embed, has a reasonable use case for wanting to request a particular size and have it potentially honored by containing page<br>
<fantasai> jensimmo_: If goal is to reduce jankiness of ad network...<br>
<fantasai> TabAtkins: that is one goal, but not all of it!<br>
<leaverou_> need to drop off briefly for another call, but I'm very supportive of this, and I hope we can find a way to implement it in a privacy and security preserving way.<br>
<astearns> ack emilio<br>
<fantasai> emilio: How do you react to resize in parent page when using the API?<br>
<fantasai> emilio: User shrinks the page, need to somehow coordinate between both. No auto size, only fixed intrinsic size<br>
<fantasai> TabAtkins: I don't think there's a reasonable direct analog to block auto-sizing ..<br>
<fantasai> emilio: I guess at that point... You don't really need JS on the parent page to get auto height<br>
<fantasai> emilio: If you require JS on the parent page then it's not great<br>
<fantasai> emilio: So inner page can send resizeTo() whenever it gets Resize event<br>
<fantasai> emilio: and then containing page doesn't need to do anything ...<br>
<fantasai> emilio: [missed]<br>
<fantasai> TabAtkins: possible this makes it easy enough that it's a concern<br>
<fantasai> emilio: resize event ... your own resize event<br>
<fantasai> TabAtkins: I suspect that's something that would show up fairly quickly<br>
<fantasai> emilio: It only consumes CPU, not while:true. I send a message, it resizes me, sends a message back. Code keeps working, just uses a ton of CPU<br>
<fantasai> emilio: It's a bug in the page, but.<br>
<fantasai> TabAtkins: no-op loops can't happen because if the iframe's resizeTo() doesn't change its size, won't get an event because size didn't change.<br>
<fantasai> TabAtkins: Either it'll grow or shrink infinitely, or will jiggle, which should be noticeable<br>
<fantasai> emilio: Concerned about e.g. floating point issues, and rounding errors<br>
<fantasai> emilio: I've seen that kind of stuff happen<br>
<iank_> we also already have the "jiggle" problem today with frame by frame resize-observers.<br>
<fantasai> if not causing change in size, then shouldn't cause a problem<br>
<fantasai> fremy: can't put a breakpoint in the main page to figure it out because no JS<br>
<fantasai> fremy: Already have these kinds of bugs today<br>
<astearns> ack fremy<br>
<fantasai> smfr: The HTML5 event loop spec is very specific about when resize steps happen<br>
<fantasai> smfr: when we spec this, we need to spec it in terms of that event loop spec<br>
<fantasai> smfr: Nobody mentioned resizeobserver yet<br>
<fantasai> smfr: it's designed to avoid infinite recursion<br>
<fantasai> smfr: we might need something here with nested iframes, so don't get into crazy infinite resizing<br>
<dholbert> q+<br>
<fantasai> TabAtkins: yes, want to handle events in descending order like resizeobserver does<br>
<fantasai> TabAtkins: need some thought to ensure not creating bad cross-tree resizing behaior<br>
<fantasai> TabAtkins: Not too concerned about page vs iframe vibration, but much worse if grandparent grandchild interactions cause problem, because then nobody knows what's going on<br>
<fantasai> fremy: Main question here was, I guess point of allow attribute is to allow resize<br>
<fantasai> fremy: External page wants to allow iframe to resize<br>
<fantasai> fremy: Not sure I understand point of resize function<br>
<dholbert> q-<br>
<fantasai> fremy: why not some CSS value that allows resizing by containing page<br>
<fantasai> fremy: reason I think about htat is that resize takes 2 arguments, width and height.<br>
<fantasai> fremy: not that interesting to change intrinsic width of iframe<br>
<gregwhitworth> +1 to fremy<br>
<fantasai> fremy: why not say that "I'm fine with my scrollHeight to be reported to the containing page"<br>
<fantasai> iank_: scrollHeight isn't always what you want<br>
<fantasai> fremy: could be something smarter, max-content maybe<br>
<astearns> q?<br>
<fantasai> TabAtkins: Second part of proposal also, about same-origin content and no-JS solution<br>
<fantasai> smfr: Other point, iframe calls resizeTo() and has to provide a size. What size should it provide? does it doe getBoundingClientRect() on the body or what?<br>
<fantasai> smfr: Is there some convenient way to get the height of the content?<br>
<fantasai> TabAtkins: For 1st-party content, making it easy. But for 3rd-party content wanted to be more explicit<br>
<fantasai> TabAtkins: But maybe we can reduce that restriction<br>
<fantasai> TabAtkins: 2nd part of proposal is about same-origin content<br>
<fantasai> TabAtkins: right now, minimum solution still requires some JS on the framed page (not containing page)<br>
<fantasai> TabAtkins: but for same-origin content, there's a certain degree of implicit trust we can rely on<br>
<fantasai> TabAtkins: and might not require auditing<br>
<fantasai> TabAtkins: for this, I propose that on a 1st-party iframe, or something that's srcdoc<br>
<fantasai> emilio: srcdoc is not ?<br>
<fantasai> emilio: data URIs are<br>
<fantasai> TabAtkins: sorry, I'm thinking about sandbox<br>
<gregwhitworth> q+<br>
<fantasai> TabAtkins: In my original proposal, I had a new property that could be set on the root element to set the requested intrinsic size for each axis (auto | <length>)<br>
<emilio> q+<br>
<fantasai> TabAtkins: page could opt into ? via 'from-element' keyword, providing fallback length<br>
<fantasai> TabAtkins: fantasai later suggested the page could just set an explicit width/height on the HTML element<br>
<fantasai> TabAtkins: Possibly we don't need to mint a new property, can just take from the root element<br>
<fantasai> TabAtkins: if that's problematic from existing, maybe mint something new<br>
<fantasai> TabAtkins: but either way, that'll allow getting the size without JS<br>
<fantasai> TabAtkins: Just set allow=resize, and inner page does whatever it needs to do<br>
<fantasai> TabAtkins: and those sizes automatically communicate back and forth<br>
<fantasai> TabAtkins: acts like an element, no JS required<br>
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925<br>
<fantasai> fremy: that only works in 1D, right? you can't do both dimensions<br>
<fantasai> fremy: then you wouldn't get the resize<br>
<fantasai> fremy: if you get width + height, wouldn't know you need more space<br>
<fantasai> TabAtkins: If you set both to auto, you'll need to rely on outer page to set your width...<br>
<fantasai> fremy: ah, ok, make sense<br>
<fantasai> iank_: I don't think that width/height on HTML will work, because people do set an explicit width on HTML and use e.g. auto margins to center<br>
<fantasai> iank_: HTML is not the root, bit of disconnect<br>
<fantasai> iank_: likely for auto behavior, might want something like scrollWidth/scrollHeight as was discussed<br>
<fantasai> iank_: There's a little bit of danger here<br>
<fremy> +1 to scrollWidth/scrollHeight (adjusted if necessary)<br>
<fantasai> iank_: you might get content that, if you have a fixed-position content that rises to ICB, and has height 120%, could create an infinitely-growing iframe that way?<br>
<fantasai> iank_: I'm not too concerned about that<br>
<fantasai> TabAtkins: Yeah, need to think about loop detection...<br>
<fantasai> fremy: we can set a threshold, if you fire too many resize events in a certain amount of time don't allow it or whateer<br>
<fantasai> iank_: That might block some valid use cases. E.g. comment expansion might want to animate growing<br>
<gregwhitworth> resizeObserver has the same error handling<br>
<astearns> ack gregwhitworth<br>
<fantasai> gregwhitworth: Effectively what you just outlined is something we wanted at Salesforce. All over the web ppl using Salesforce but not aware of it.<br>
<fantasai> gregwhitworth: would like to see ???<br>
<fantasai> gregwhitworth: enable this auto behavior for cross-origin<br>
<fantasai> gregwhitworth: if a grid with min/max content, how can I lay out my content and pass back my height<br>
<astearns> s/???/network headers/<br>
<fantasai> gregwhitworth: I can work it out in JS, but want it automatic<br>
<fantasai> TabAtkins: Reason restricted right now is trying to be cautious<br>
<fantasai> gregwhitworth: we could write blog posts about how to do it, but would rather not<br>
<fantasai> TabAtkins: I would want to have more security eyes on it<br>
<fantasai> gregwhitworth: ...<br>
<fantasai> emilio: There is some kind of precedent for this, loading a doc and sizing it intrinsically, which is SVG<br>
<fantasai> emilio: Even if the SVG is not an actual image, if you have an object tag with SVG source, that's actually a document that's ...<br>
<fantasai> emilio: in FF and Chrome at least, that size is intrinsic to SVG's viewbox<br>
<fantasai> emilio: it would be good to figure out if there's something that we need to learn from that or not<br>
<fantasai> emilio: that's probably legacy behavior<br>
<fantasai> emilio: While we were doing ??<br>
<fantasai> emilio: I just wanted to mention that precedent<br>
<fantasai> emilio: I think those can run script, even if SVG<br>
<dlibby> s/??/site isolation/<br>
<fantasai> TabAtkins: A few people in thread mentioned OBJECT<br>
<fantasai> TabAtkins: If currently allows that behavior and think it's OK, then maybe can allow it<br>
<fantasai> TabAtkins: I haven't thought about it yet<br>
<astearns> ack emilio<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: on the topic of 3rd party sizing info without JS, I think i tmakes sense to allow<br>
<TabAtkins> fantasai: If both the container and the inner page have explicitly allowed for it<br>
<TabAtkins> fantasai: That indicates trust between the two<br>
<TabAtkins> fantasai: For doing it declaratively, Ian's pointa bout width/height on root not being what we want makes sense<br>
<TabAtkins> fantasai: Tab mentioned setting a property giving the behavior explicitly<br>
<TabAtkins> fantasai: I don't think that's a CSS property, it's more of a security handshake<br>
<gregwhitworth> +1 fantasai<br>
<dholbert> q+<br>
<TabAtkins> fantasai: So maybe an attribute on <html> that opts the iframe'd page into the behavior<br>
<TabAtkins> fantasai: And would let you specify which size you want (scroll height, border-box height, etc)<br>
<fantasai> fantasai: I think the size shouldn't be specified in HTML, should be in CSS; but allowing this should be an HTML attribute<br>
<fantasai> dholbert: Should any page on the internet be able to get that info?<br>
<fantasai> dholbert: maybe same-origin addresses it<br>
<fantasai> dholbert: don't want to allow inadvertent stealing of info from the page<br>
<fantasai> TabAtkins: right, which was why I initially wanted to disallow it<br>
<fantasai> TabAtkins: and fantasai was talking about explicit opt-in<br>
<fantasai> TabAtkins: I think there's some kind of iframing options setting?<br>
<fantasai> iank_: There's ??? HTTP Header which restricts which origins you can be embedded in. Most banks etc. use that.<br>
<fantasai> TabAtkins: requiring that, reasonable thing to start with<br>
<fantasai> iank_: would need to set Access-control: allow-origin or whatever<br>
<fantasai> astearns: Sounds like you got some good feedback, something to work on<br>
<fantasai> TabAtkins: plan is that parts of this that relevant to CSS would go to contain spec<br>
<fantasai> TabAtkins: and sizing spec<br>
<fantasai> TabAtkins: to talk about natural size being controllable this way<br>
<fantasai> TabAtkins: if we do have a new property... probably in sizing? maybe contain?<br>
<fantasai> TabAtkins: rest will be pursued in HTMLWG<br>
<fantasai> astearns: Should CSS part depend on the HTML part being accepted?<br>
<fantasai> TabAtkins: sure<br>
<myles> q+<br>
<astearns> ack dholbert<br>
<astearns> ack myles<br>
<fantasai> myles: This entire discussion about how / technical considerations. Not about whether to do it all.<br>
<fantasai> myles: Want to make sure that it's not a foregone conclusion that we should do this.<br>
<fantasai> TabAtkins: Decent part of this was sussing out whether there's interest in doing this<br>
<fantasai> TabAtkins: seems people are interested<br>
<fantasai> TabAtkins: I suspect discussion in HTMLWG will be more contentious<br>
<fantasai> TabAtkins: OK to object over there :)<br>
<fantasai> astearns: but feel free to object over here also, if you think it's a terrible idea!<br>
<fantasai> TabAtkins: We don't have any major internal partners clamoring for this, it's an old issue that's a frequent author requested, and we found a way to address an important part of it<br>
<TabAtkins> <br dur=12min><br>
<fantasai> <br duration=12min><br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-814238261 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 April 2021 16:01:02 UTC