Bug 261741

Created attachment 467751 [details] Patch

Comment on attachment 467751 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=467751&action=review > COMMIT_MESSAGE:4 > + MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit what happened here?

(In reply to Antti Koivisto from comment #2) > Comment on attachment 467751 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=467751&action=review > > > COMMIT_MESSAGE:4 > > + > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > what happened here? yea, not sure. don't see it on my computer.

Created attachment 467762 [details] [fast-cq]Patch

Committed 268148@main (7d4f344fa9a7): <https://commits.webkit.org/268148@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 467762 [details].

Hi! One followup question for the WebKit developers involved here -- the commit message here mentions the following: > 2. we do construct render tree for the “display: none” iframe’s content > we do #2 because JS may ask for geometry information on content inside a “display: none” iframe. https://github.com/WebKit/WebKit/commit/7d4f344fa9a70f3b92972faeaf1352c03d384b74 Question: are you aware of websites that actually do this (queries the layout inside of a display:none iframe) & depends on that working? I ask because: as far as I can tell, Firefox and Chrome *do not support this*; they just return 0 to queries of that layout information. So at this point, this seems to be a WebKit-specific behavior. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1883997 on the Mozilla side to track this behavior-difference. Any info you can provide here might help us assess the priority of hypothetically implementing this (or not) in Firefox. Thanks!

(In reply to Daniel Holbert from comment #6) > Question: are you aware of websites that actually do this (queries the > layout inside of a display:none iframe) & depends on that working? See bug 107236, https://github.com/whatwg/html/issues/1813 and https://github.com/w3c/csswg-drafts/issues/571. I don't think we're interested in changing Firefox behavior here, but maybe WebKit should fix bug 107236 to get interop across all browsers? :)

> Question: are you aware of websites that actually do this (queries the > layout inside of a display:none iframe) I ran a very limited, at-a-desk type of telemetry since I was curious myself whether this behavior was specific to office.com (btw office.com content has changed since) and stopped after finding a few examples. > & depends on that working? that I don't know. I did not test whether they expected "what if this iframe was visible" geometry. > I ask because: as far as I can tell, Firefox and Chrome *do not support > this*; they just return 0 to queries of that layout information. So at this > point, this seems to be a WebKit-specific behavior. I did test both Firefox and Chrome and noticed this mismatching behavior. At the time of this fix I was not interested in changing WebKit's behavior (though I think WebKit should align)

(In reply to zalan from comment #8) > I did test both Firefox and Chrome and noticed this mismatching behavior. At > the time of this fix I was not interested in changing WebKit's behavior > (though I think WebKit should align) Thanks for the reply! It looks like bug 107236 is the WebKit bug that tracks aligning with Firefox/Chrome here (and smfr is/was on-board, as of https://github.com/whatwg/html/issues/1813#issuecomment-249594340 at least where he filed a bug that was duped to that one.)

(In reply to Daniel Holbert from comment #9) > It looks like bug 107236 is the WebKit bug that tracks aligning (Oh right, Emilio already linked to that. Sorry for the repetition. :) )

(In reply to Daniel Holbert from comment #9) > (In reply to zalan from comment #8) > > I did test both Firefox and Chrome and noticed this mismatching behavior. At > > the time of this fix I was not interested in changing WebKit's behavior > > (though I think WebKit should align) > > Thanks for the reply! > > It looks like bug 107236 is the WebKit bug that tracks aligning with > Firefox/Chrome here (and smfr is/was on-board, as of > https://github.com/whatwg/html/issues/1813#issuecomment-249594340 at least > where he filed a bug that was duped to that one.) sounds like webkit has a plan! :)