1366526 - Gmail buttons have no background

Status: RESOLVED DUPLICATE of bug 1182775

(Web Compatibility :: Site Reports, enhancement)

Description

[Trevor Rowbotham [:rowbot]]

Sorry to be the bearer of bad news, but Bug 1337655 caused buttons in Gmail to not have a background.

The CSS for the buttons has the following rule:

> .TI .T-I-ax7, .z0 .T-I-ax7, .G-atb .T-I-ax7 {
>	background-color: transparent;
>	background-image: -moz-linear-gradient(top,#f5f5f5,#f1f1f1);
>	background-image: linear-gradient(top,#f5f5f5,#f1f1f1);
>	background-image: -moz-linear-gradient(top,#f5f5f5,#f1f1f1);
> }

Although, they include the standard |linear-gradient()| call, they are missing the standard |to| keyword since they are using the |top| keyword to refer to a side. Seems like we should contact Google and ask them to fix this.

Comment 1

[Xidorn Quan [:xidorn] UTC+11]

We should contact Google for that, and we should probably stop removing moz-prefix gradient given this. I'd probably wait for another while and see if there are other compat reports before switching back the pref in nightly.

Comment 2

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

Could you revert the pref flip in nightly for now?

Comment 3

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

(and probably directly on mozilla-central, since inbound/autoland may not merge for a few days)

Comment 4

[Anthony Ramine [:nox]]

I notice that -moz-linear-gradient(top,#f5f5f5,#f1f1f1) could be very well parsed as a 2011 -webkit-linear-gradient compat syntax, so maybe we could just do that? I mean that as an alternative to having to implement -moz gradients in Stylo or unshipping them entirely.

As a side note, neither Safari nor even Chrome understand linear-gradient(top,#f5f5f5,#f1f1f1).

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

I've reverted the pref change in bug 1337655, so let's turning this into a Tech Evangelism since we may still want to drop moz-prefixed gradient at some point.

Comment 6

[Rick Byers]

Sorry for the GMail trouble here.  I had already filed this bug with the GMail team (b/37095388) since it reproduces in the latest Edge 15 builds as well.  They assume all the different prefixed gradients use the same syntax as the -webkit one, yet only send the -webkit (which would actually work in all modern browsers) to Chrome and Safari.  I will continue to try to get this fixed.

Worst case if this class of issues continues to be a pain for you, perhaps it wouldn't be completely crazy for us to consider trying to drop support for the -webkit version from Chrome?

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Rick Byers from comment #6)
> I had already filed this bug with the
> GMail team [...] yet only send the -webkit (which would actually work in
> all modern browsers) to Chrome and Safari.  I will continue to try to get
> this fixed.

Thank you! Either fixing the modern syntax or sending the -webkit syntax unconditionally would be acceptable solutions.
 
> Worst case if this class of issues continues to be a pain for you, perhaps
> it wouldn't be completely crazy for us to consider trying to drop support
> for the -webkit version from Chrome?

I'm intrigued but skeptical about that possibility. (Usage is low, but it's high enough -- and the degradation is painfully-un-graceful enough -- that the breakage would be prohibitive, I suspect.)

For the time being, for Bug 1337655, we only need to be concerned with sites that *rely* on -moz prefixed gradients in Firefox (e.g. due to UA-sniffing & sending different CSS to different browsers), like GMail does & like Facebook used to (bug 1183504).

That's hopefully a much narrower problem than the problem of unshipping -webkit gradient support in Chrome. :)  Hopefully there aren't too many such sites.

Please let us know if you can determine an ETA for the GMail fix. If it's not soon, we'll need to consider adding -moz prefixed gradient support to Servo's CSS engine so that we don't break GMail when we experiment with dropping that in.

Comment 8

[Mike Taylor [:miketaylr]]

(setting to sitewait since Rick filed a bug for us -- thanks!)

Comment 9

[Daniel Holbert [:dholbert]]

This is the same issue we hit the last time we tried to un-ship gradient support. :-/  Compare comment 0's CSS to bug 1182775 comment 3 -- they're basically the same.

That bug was resolved as WFM because we had a report from a user that it had been fixed on Google's end, but apparently the fix un-shipped [or it was never fixed at all & was only hidden by the fact that we were still honoring moz-prefixed gradients].

I've reopened that bug & I'm going to dupe this to that bug & transfer flags/whiteboard status.

Comment 10

[Karl Dubost💡 :karlcow]

Rick,

(In reply to Rick Byers from comment #6)
> Worst case if this class of issues continues to be a pain for you, perhaps
> it wouldn't be completely crazy for us to consider trying to drop support
> for the -webkit version from Chrome?

That would be wonderful, but remember that we and Edge had to implement -webkit- because of these specific issues. You would need to assess the pain in Asian markets (China/Japan) specifically.

Another idea that could be interesting to explore is that you drop the -webkit- prefixes in Chrome when there is a stable version for all Google properties only. A kind of internal addons/extension that would target specific sites. This is interesting on a couple of levels.

1. It has a "eat your own dog food" turn
2. It helps the Web by making Google Web properties more standard (and it's a big chunk)
3. It helps other browsers to have access to the sites.
4. It creates an internal dialog inside Google with more leverage than having to help Firefox, Edge users.

Comment 11

[Rick Byers]

Thanks Karl, that's not a crazy idea ;-).  In your experience, of the google-specific site compat issues, what fraction would be helped (i.e. Firefox and Chrome behavior aligned) by this?  I was guessing it would be only a small fraction, but maybe I'm wrong?  Certainly I've seen some other cases.

Comment 12

[Karl Dubost💡 :karlcow]

hehe. It depends on we look at the issue. 
Most of our Web compatibility issues for Google properties are related to user agent sniffing serving a different version to Firefox users. 

Once we do user agent override for getting the tier1, we run into the territory of -webkit- which forced us to implement/alias those which were common. My reasoning is that if there are less reasons for the tier1 experience to depends on -webkit- (CSS/JS). It's easier to negotiate the tier1 OR for us to just do UA override. 

As for the number, 2 years and a half ago I went through all the Google properties issues I could redo that. Probably a lot less since our implementation of webkit and the death of Firefox OS.