1238527 - Unwanted gradient behind text on https://stripe.com/relay

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Markus Stange [:mstange]]

On https://stripe.com/relay, there's a gradient behind the text "Let customers buy your products directly within other mobile apps."
This gradient comes from a background: -webkit-linear-gradient(...) declaration. There is no corresponding linear-gradient declaration.

In Safari, this gradient is clipped to the text using -webkit-background-clip: text. So the page is assuming that all browsers that support the -webkit-linear-gradient syntax also support -webkit-background-clip: text, which I think was a reasonable assumption.

Comment 1

[Mike Taylor [:miketaylr]]

As mentioned in Bug #1238550 here's the style in question: 

section.hero .content section.copy p {
  margin-bottom: 1.8em;
  font-size: 2em;
  color: #f0c0e5;
  background: -webkit--webkit-linear-gradient(90deg, #dca2ef, #ffd2df);
  background: -webkit--moz-linear-gradient(90deg, #dca2ef, #ffd2df);
  background: -webkit--o-linear-gradient(90deg, #dca2ef, #ffd2df);
  background: -webkit--ms-linear-gradient(90deg, #dca2ef, #ffd2df);
  background: -webkit-linear-gradient(0deg, #dca2ef, #ffd2df);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}

I'll report this to a friend at Stripe, but I can't think of any magical workarounds to us not supporting this non-standard property. :(

Comment 2

[Mike Taylor [:miketaylr]]

I brought this up to my friend and they were brainstorming ways to make this work (it turns out the -webkit-prefixed prefixes was just a preprocessor bug).

They have a similar style on https://stripe.com/checkout, but we don't parse that gradient so the ugly gradient-background-on-p problem isn't visible:

body#checkout #slide0 > p {
    top: 270px;
    font-size: 34px;
    line-height: 1.2;
    color: #c5b3cb;
    background: -webkit-linear-gradient(0,rgba(180,180,250,0.7),#fadce5 50%,#fff);
    -webkit-background-clip: text;
    -webkit-text-fill-color: transparent;
}

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Mike Taylor [:miketaylr] from comment #2)
> we don't parse
> that gradient so the ugly gradient-background-on-p problem isn't visible:

I'd consider that a bug on our part (not parsing that -webkit-linear-gradient expression), so it'd probably be fragile for authors to lean on that as a workaround.

Comment 4

[Mike Taylor [:miketaylr]]

(Yeah, to be clear I wasn't suggesting they re-use that expression -- just pointing out another instance of the same problem).

Comment 5

[Daniel Holbert [:dholbert]]

OK, thanks. I spun off bug 1239153 for that -webkit-linear-gradient parsing bug, FWIW.

Comment 6

[Daniel Holbert [:dholbert]]

Possible workaround: they could use "@supports not" to detect non-support of "-webkit-background-clip: text", and set the background to transparent inside of that clause.
Something like the following (untested):

@supports not(-webkit-background-clip: text) {
  section.hero .content section.copy p {
    /* disable bg gradient, since text can't be clipped to it */
    background: transparent;
  }
}
https://developer.mozilla.org/en-US/docs/Web/CSS/@supports#Testing_for_the_non-support_of_a_specific_CSS_property

Comment 7

[Daniel Holbert [:dholbert]]

(In an ideal world, they'd use "@supports" to detect *positive* support of "-webkit-background-clip: text". But that would mean iOS Safari 8.4 users would get a suboptimal experience, since they don't recognize @supports at all, as noted in bug 1225661 comment 2.  Hence my suggestion to use "@supports not".)

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 46 as it's affected and I think this is a recent regression from the duplicates and related bugs. Does this also affect 47?

Comment 10

[Mike Taylor [:miketaylr]]

Yes, this affects 47 but won't ship past Aurora (see Bug 1238827). 

(Not sure how tracking releases works when certain regressions stick in non-release builds.)

Comment 11

[Daniel Holbert [:dholbert]]

(And this will continue to be broken in Nightly/Aurora until bug 759568 is fixed).

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

I'll just track it in 47 for now, and leave it in your hands.  If you end up with a fix in bug 1248785 then please request uplift. Thanks for checking!

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: screenshot of the bug

Comment 14

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

I just had a quick chat with Dholbert about this and he mentioned that bug 759568 will be fixed in 48 cycle. Updating status-firefox47 to reflect that and moving the tracking flag to 48. Also, this is not an issue on release+beta builds so we should be ok for 47.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Ritu Kothari (:ritu) from comment #14)
> I just had a quick chat with Dholbert about this and he mentioned that bug 759568
> will be fixed in 48 cycle.

I'm not 100% sure about that, but there's a good chance it'll be fixed in 48 cycle, since CJ is actively working on it.

> and moving the tracking flag to 48. Also, this is not an issue on
> release+beta builds so we should be ok for 47.

This all makes sense to me. Thanks!

Comment 16

[Chris Peterson [:cpeterson]]

I see a similar problem where a gradient is applied to the text background instead of the text on this website:

https://www.lucid.ai/case-studies/u-s-forest-service

Scroll down to the "It all came down to one thing: red tape." header. Or click the hamburger button in the upper-right corner of the page to see the gradient problem on a text menu.

Comment 17

[Daniel Holbert [:dholbert]]

Thanks Chris -- that does indeed look like another instance of this bug.  Hopefully should be good once we've solved bug 759568. (and this won't be an issue past Aurora in the meantime, as discussed above.)

Comment 18

[u459114]

Yes, this one can be fixed by bug 759568.

Comment 19

[Daniel Holbert [:dholbert]]

One more instance of this: ADP (mozilla's paystub processor, in the US at least).

STR (if you have an account on ADP):
 1. Visit https://workforcenow.adp.com/
 2. Log in.
 3. Look at throbber in the middle of the page while the webapp loads.

The throbber has a weird background, which comes from this styling:
.revolution .revitLoadingOverlayIcon {
	font-size: 3.0em;
	color: #1e92af;
	background: -webkit-linear-gradient(57deg, #1e92af 0%, rgba(255, 255, 255, 0) 79%);
	-webkit-text-fill-color: transparent;
	-webkit-background-clip: text;
}

Comment 20

[Daniel Holbert [:dholbert]]

Attachment: Screenshot of bug at ADP

Comment 21

[Mike Taylor [:miketaylr]]

Attachment: Dev Edition vs Nightly

This is fixed in Nightly, w/ layout.css.background-clip-text.enabled and layout.css.prefixes.webkit set to true.

Comment 22

[Daniel Holbert [:dholbert]]

--> Resolving as FIXED by bug 759568, per comment 21.

(That pref-configuration is the default configuration on Nightly.  And we won't enable layout.css.prefixes.webkit by default for release builds until we're confident we can also enable layout.css.background-clip-text.enabled by default as well.  And that means this bug shouldn't ever occur in release builds. So, I don't think there's any value to keeping this open.)

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Stop tracking (cf comment #22)

Comment 24

[Daniel Holbert [:dholbert]]

We can call this "disabled" (rather than "wontfix") for pre-Firefox-49 releases, since this bug was triggered by the webkit prefix about:config pref, and we're not enabling that pref in release until Firefox 49 (via bug 1259345).