1584088 - Firefox doesn't apply inline style contents if inner @import hasn't finished loading (like WebKit), but Chrome does

Status: NEW

(Core :: CSS Parsing and Computation, defect, P3)

Description

[elrumordelaluz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Since the first attempt was using react.js, after discard that the current behaviour is not related to the framework I can confirm that only in Firefox, the offset calculations for a DOM element are different between the first render and the following ones.

Here is a sandbox using React and here is a sandbox without React (using Parcel)

The interesting part is that trying to reproduce in a codepen, the issue seems to be solved. I hope this last information could be useful to debug each use case.

Actual results:

The first render the red outline's width is large as an h1 default styles (display:block and default font) and after hide/show it using the button, the outline match the h1 styles. Here a screen recording

Expected results:

The measurement should match the DOM element with styles applied.

Here is a screen capture comparing the behaviour between Safari (left one), Chrome (right bottom) and Firefox (right top)

Comment 1

[Sebastian Padilla]

Hi elrumordelaluz,

Thanks for submitting this bug to us. The info that you provided us was very useful! I was able to reproduce it on macOS Mojave 10.14 using Firefox Nightly 71.0a1 (64-bit - 2019/09/30) and Firefox 69.0.1 (64-bit)

I'm going to add a Product and a Component so a dev can take a look at this.

Thanks!

Sebastian

Comment 2

[Edgar Chen [:edgar] (OOO untils 09/01, slow response)]

This looks like a layout issue to me.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Attachment: Testcase

There's nothing that guarantees that the @import (and thus the <style> element) is applied by the time you call init(), and thus you're not getting the stylesheet to apply.

WebKit (Safari) behaves like Firefox, see the attached test-case for a reduced example.

It seems like Chrome applies the inline style contents partially, even if the @import hasn't loaded yet... That's pretty weird.

Boris have you seen this one before? Do you know what if anything is supposed to define the behavior here?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case with <link>.

This behaves the same in all three browsers. Not sure why they'd be different.

I think we should close this and file a chromium bug, unless people feel strongly otherwise.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case with <link>.

Using https so that the load isn't blocked.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Testcase.

(same)

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1009997.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Boris have you seen this one before?

I don't think so...

Do you know what if anything is supposed to define the behavior here?

Mmm. So the HTML spec bit that's relevant is that when the <style> element is inserted into the DOM https://html.spec.whatwg.org/multipage/semantics.html#update-a-style-block gets called. Modulo the detail of https://github.com/whatwg/html/issues/2997 the text then says:

Once the attempts to obtain the style sheet's critical subresources, if any, are complete, or, if the style sheet has no critical subresources, once the style sheet has been parsed and processed, the user agent must run these steps:

which is all about firing load events and updating the script-blocking state and whatnot. Critically, it says nothing about when rules start applying, if ever; that's up to the CSS WG, and they have not been very forthcoming about speccing it, for going on a decade now.

Oh, and even the definition of "critical subresources" is not well-defined and is in the CSS WG wheelhouse. https://html.spec.whatwg.org/multipage/infrastructure.html#critical-subresources exists, and says @import ought to be critical, but in Chrome at one point direct @import was critical but nested @import was not; now idea whether that's still true. And as the note says https://github.com/w3c/csswg-drafts/issues/1088 is open on the general problem. But, again, nothing says that "load event" and "when the rules start applying" is the same point in time.

Summary: This is all totally undefined, and the CSS WG needs to define it.