1605803 - content property of getComputedStyle is being returned as none

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Ksenia Berezina [:ksenia] on leave until 09/15]

Attachment: 46914.html

As reported here https://github.com/webcompat/web-bugs/issues/46914

Steps to reproduce:

Visit https://webgis.ci.brookfield.wi.us/BrookfieldWebMap/ and observe the site

Actual:
Map doesn't load

Expected:
Map loads

The problem seems to be that getComputedStyle(element)).content is none, however the site is expecting it to be normal. I've attached a reduced test case.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Blink / WebKit returns none for pseudo-elements getComputedStyle(element, "::before").content, but normal for elements...

And Safari returns the empty string, yay interop :-(

Is this broken in Safari as well?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Pff, probably not, from the snippet: b && "normal" != b ? d([eval(b)], c) : c(), so the empty string means we'll never test for normal...

Ugh.

Comment 3

[Ksenia Berezina [:ksenia] on leave until 09/15]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Pff, probably not, from the snippet: b && "normal" != b ? d([eval(b)], c) : c(), so the empty string means we'll never test for normal...

Ugh.

Yeah, working in Safari because of this exact reason :(

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1605803 - Use cbindgen for content property. r=#style

This cleans up and also allows us to keep the distinction between content: none
and content: normal, which allows us to fix the computed style we return from
getComputedStyle().

Do this last bit from the resolved value instead of StyleAdjuster, because
otherwise we need to tweak every initial struct for ::before / ::after.

Comment 5

[Oriol Brufau [:Oriol]]

BTW, this is the hack that Chromium uses: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/properties/computed_style_utils.cc?rcl=70c8dc746602493b5e49a50365ce3e636e15c205&l=1902-1907

  if (!list->length()) {
    PseudoId pseudoId = style.StyleType();
    if (pseudoId == kPseudoIdBefore || pseudoId == kPseudoIdAfter)
      return CSSIdentifierValue::Create(CSSValueID::kNone);
    return CSSIdentifierValue::Create(CSSValueID::kNormal);
  }

If you plan to store content: normal and content: none as different values because of bug 1605473, will you also support content: none in elements? Or will it just compute as a different value but will still behave like content: normal?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

I plan to make it compute a different value but still behave like normal.

That's a bit unfortunate... Implementing none on elements should be simple, but probably worth a separate bug. Probably worth making content: none compute to normal on elements too for now.

I also filed https://github.com/w3c/csswg-drafts/issues/4632 on content: contents which would break this website as well.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fc3002cb85dc
Use cbindgen for content property. r=xidorn

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/21042 for changes under testing/web-platform/tests

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 10

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/fc3002cb85dc

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot