1093260 - Property contained reference to invalid variable. Error in parsing value for 'transform'. Falling back to 'initial'.

Status: NEW

(Core :: General, defect)

Description

[:Gijs (he/him)]

Still seeing the equivalent of bug 1088789 on current fx-team tip:

Property contained reference to invalid variable.  Error in parsing value for 'transform'.  Falling back to 'initial'.

pointing to:

    transform: translateY(calc(0px - var(--space-above-tabbar)));


Not really sure what's going on, to be honest, because we use the same variable elsewhere and it seems to work there?

Brian?

Comment 1

[Brian Grinstead [:bgrins]]

When / where are you seeing this? Even when moving that rule outside of the lion media query and opening a private browsing window I don't see any warnings in the Browser Console.

Comment 2

[:Gijs (he/him)]

(In reply to Brian Grinstead [:bgrins] from comment #1)
> When / where are you seeing this? Even when moving that rule outside of the
> lion media query and opening a private browsing window I don't see any
> warnings in the Browser Console.

I'm on 10.9.5 still, and see this when the window opens, in the browser console (on current fx-team tip)

Comment 3

[Brian Grinstead [:bgrins]]

OK, I'm not seeing it on 10.8.5, but I will investigate more to see if I can trigger the warning

Comment 4

[:Gijs (he/him)]

In case it's helpful:

1. ./mach run (which will be a clean profile)
2. cmd-shift-j
3. click the 'css' icon twice to show css messages (yeah, I don't know what's up with that, different bug...)

shows this for me...

Comment 5

[Brian Grinstead [:bgrins]]

OK, I'm seeing it now too.  Here is something weird:

The warning goes away if I change it to: 

  #TabsToolbar > .private-browsing-indicator {
    --space-above-tabbar: 9px;
    transform: translateY(calc(0px - var(--space-above-tabbar)));
    /* ... */
  }

Likewise, no warning shows up if I use this instead:

  :root {
    transform: translateY(calc(0px - var(--space-above-tabbar)));
  }

Comment 6

[Brian Grinstead [:bgrins]]

I also considered that it could have had something to do with the -moz-mac-lion-theme media query, but the warning continues even if I move the block outside of that.

Comment 7

[Brian Grinstead [:bgrins]]

The plot thickens.. There is no warning on:

#TabsToolbar
#TabsToolbar > foobar
#TabsToolbar > .foobar
#TabsToolbar > .titlebar-placeholder

And there is a warning on:

#TabsToolbar > .private-browsing-indicator
.private-browsing-indicator

BUT, if I add display: none to #TabsToolbar > .titlebar-placeholder, I do see the warning:

  #TabsToolbar > .titlebar-placeholder {
    transform: translateY(calc(0px - var(--space-above-tabbar)));
  }

Comment 8

[Brian Grinstead [:bgrins]]

That last snippet from Comment 7 should have been:

  #TabsToolbar > .titlebar-placeholder {
    transform: translateY(calc(0px - var(--space-above-tabbar)));
    display: none;
  }

And the really weird thing is that the transform actually seems to be applying despite the warning (the tabs get moved up 9px)

Comment 9

[:Gijs (he/him)]

(In reply to Brian Grinstead [:bgrins] from comment #8)
> That last snippet from Comment 7 should have been:
> 
>   #TabsToolbar > .titlebar-placeholder {
>     transform: translateY(calc(0px - var(--space-above-tabbar)));
>     display: none;
>   }
> 
> And the really weird thing is that the transform actually seems to be
> applying despite the warning (the tabs get moved up 9px)

Sounds like it's time to ask layout/css parsing people what's up with this?

Comment 10

[Brian Grinstead [:bgrins]]

Hi David, I'm running into a bit of a weird warning with CSS variable usage and I'm wondering if you'd be able to help figure out what is going on.  Here is the most minimal case I can come up with to reproduce the warning.  If you replace the entirety of browser.css with this:

  :root {
    --space-above-tabbar: 9px;
  }
  #TabsToolbar > .titlebar-placeholder {
    transform: translateY(calc(0px - var(--space-above-tabbar)));
    display: none;
  }

You should see this warning in the Browser Console (you may have to toggle the browser console CSS button twice - see Comment 4):

  Property contained reference to invalid variable.  Error in parsing value for 'transform'.  Falling back to 'initial': browser.css:6.

If I remove the display: none from the rule, then the warning goes away.

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I don't see anything obvious, but maybe heycam might know.

I'm also not on mac, which makes it harder to poke around.

Comment 12

[Cameron McCormack (:heycam)]

Thanks for the reduced test, Brian.

When we get the warning for the element with the transfom property, we're resolving its style here:

  http://mxr.mozilla.org/mozilla-central/source/dom/base/Element.cpp#397

It's passing null as the parent style context, which is why it doesn't see any variables inherited from the root element.  So not only would this cause |-moz-binding: var(--some-url)| to be broken, but also |-moz-binding: inherit|.

I *think* the thing with display:none is that for displayed elements we look up the value of -moz-binding during frame construction, and there we've done a proper style resolution for the element.

Passing null as the parent goes back to hg@1.

Boris, do you think we should be passing in a real parent style context here, and if so, where can we get one from?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Welcome to XBL sucking.

Really, all we want to know here is the -moz-binding value.  We couldn't care less about any of the rest of the style data.  We also obviously don't support "-moz-binding: inherit" here, as you note or bindings applied based on anything other than the element itself, really.  Except when we do; it really depends on the JS code flow.

Getting a real parent style context for this backwards compat hack is complicated, especially because in many cases there isn't one to be had at all.  For example, if the Element in question is the root of a subtree getting cloned...

OK, that's the bad news.  The good news is that we could probably just check whether we're the root element, and if not, and if the root element has a primary frame, use the style context of that frame as the parent.

But... this warning has deeper issues.  Consider a testcase like so:

  <style>
  :root {
      --foo: 100px;
  }
  div {
      transform: translateY(calc(0px + var(--foo)));
  }
  </style>
  <script>
    var div = document.createElement("div");
    var disp = getComputedStyle(div).display
  </script>

This produces the warning, for the same reason as in the XBL case...

Comment 14

[Cameron McCormack (:heycam)]

Bug 952338, which I'd forgotten about, is preventing computed-value-time re-parsing of properties with variable references from reporting warnings to the Web Console.

I'm starting to wonder whether these warnings are useful.  They can be reported at odd times -- as with your example, it gets reported because we're computing the Display style struct.  That also means you can get it repeated many times as you change style on an element.

Maybe instead the dev tools Computed Style panel can somehow indicate that a property with a variable reference was re-parsed but this failed.  And then we don't report the warning to the Web Console at all.

David, do you have any thoughts?

Comment 15

[Brian Grinstead [:bgrins]]

(In reply to Cameron McCormack (:heycam) from comment #14)
> Maybe instead the dev tools Computed Style panel can somehow indicate that a
> property with a variable reference was re-parsed but this failed.  And then
> we don't report the warning to the Web Console at all.

If there was a failure when parsing a CSS variable due to a typo or something, I'd still like to see something in the console so it was very visible.

It would be very cool to see a trace of how a variable's value was assigned in the computed styles pane (including data about failures).

Comment 16

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to Cameron McCormack (:heycam) from comment #14)
> Bug 952338, which I'd forgotten about, is preventing computed-value-time
> re-parsing of properties with variable references from reporting warnings to
> the Web Console.
> 
> I'm starting to wonder whether these warnings are useful.  They can be
> reported at odd times -- as with your example, it gets reported because
> we're computing the Display style struct.  That also means you can get it
> repeated many times as you change style on an element.
> 
> Maybe instead the dev tools Computed Style panel can somehow indicate that a
> property with a variable reference was re-parsed but this failed.  And then
> we don't report the warning to the Web Console at all.
> 
> David, do you have any thoughts?

I'm a little hesitant to design too much around this 'binding' property use case.

It seems like we ought to warn, but perhaps ought to find a way to warn only once.  I'm not sure how, though.

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Bug 1160724 is changing the special code for computing 'binding'.