Bug 261741 – Office.com is slow to respond

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[zalan]

<rdar://112494003>

[zalan]

Created attachment 467751 [details]
Patch

[Antti Koivisto]

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?

[zalan]

(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.

[zalan]

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

[EWS]

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].

[Daniel Holbert]

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!

[Emilio Cobos Álvarez (:emilio)]

(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? :)

[zalan]

> 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)

[Daniel Holbert]

(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.)

[Daniel Holbert]

(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. :) )

[zalan]

(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! :)