1231829 - Implement -webkit-border-image quirks for compatibility

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[Mike Taylor [:miketaylr]]

Bug 837211 added an alias for shorthand -webkit-border-image to unprefixed border-image.

We need to add the following quirks for compat:

-webkit-border-image assumes "fill" if a slice is specified (cf. http://codepen.io/anon/pen/LGYjxM). Edge implements this.

border-style: solid needs to be assumed (cf. https://bugzilla.mozilla.org/show_bug.cgi?id=995140#c18 and http://codepen.io/anon/pen/KVprar -- for that one, we should "fail" to pass, if that makes sense.)

Comment 1

[Daniel Holbert [:dholbert]]

The tricky thing here is that by the time we're parsing the value, "it's too late", because we've already converted from the alias string into the standardized nsCSSProperty value, and we have no knowledge that we're actually parsing an alias.

I discussed this with dbaron yesterday, and we came up with one possible solution: when the css parser is parsing a property, and it converts from the (prefixed) property-name-string to the "target" unprefixed nsCSSProperty value, we can make a note of the fact that we have an alias, and what the alias is (its nsCSSProperty value).  Then, later on when we're parsing a border-image value, we can see if we made a note for ourselves & we're really parsing -webkit-border-image, and adjust our behavior accordingly.

This could be done via a nsCSSProperty member-var on CSSParserImpl, which we'd set after we call LookupEnabledProperty (to do the string-to-nsCSSProperty mapping) and which we'd clear with the magic of an RAII AutoRestore object.  For this to work, LookupEnabledProperty and its helper nsCSSProps::LookupProperty would need to change slightly to be able to return (via an outparam perhaps) the alias nsCSSProperty enum-value (if applicable), along with the standard unprefixed nsCSSProperty enum-value that it returns currently.

Comment 2

[Daniel Holbert [:dholbert]]

I believe one of the key use-cases here (with quirky -webkit-border-image) was Google Calendar, per bug 995140 comment 14.

Happily, according to bug 995140 comment 23, Google Calendar has now removed this quirky usage.

So, there's perhaps less urgency behind this bug here (unless we're aware of other quirky usages at high-profile sites).  Still worth fixing eventually, though -- particularly for consistency with how we're intending to spec -webkit-border-image.

Comment 3

[Mike Taylor [:miketaylr]]

Yep, Google properties were the most important sites on our radar for these quirks. Let's keep an eye on future bustage as we find out about it and use that to help prioritize.

Comment 4

[Daniel Holbert [:dholbert]]

Looks like Gmail may also need the "fill" quirk, for now at least:
 https://github.com/webcompat/web-bugs/issues/1333#issuecomment-184468655

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)
> The tricky thing here is that by the time we're parsing the value, "it's too
> late", because we've already converted from the alias string into the
> standardized nsCSSProperty value, and we have no knowledge that we're
> actually parsing an alias.
> 
> I discussed this with dbaron yesterday, and we came up with one possible
> solution: [...]

I've got this strategy implemented as Bug 1231682 part 1, BTW.  (attached in bug 1231682 comment 2).

Comment 6

[Daniel Holbert [:dholbert]]

An update here:
 * Google says they're working on fixing Gmail to not depend on this quirk, in b/25961635  (via email as well as via https://bugs.chromium.org/p/chromium/issues/detail?id=559258#c37 ).
 * Chrome 51 (current trunk) should be getting a patch to match Firefox on this very soon (maybe within a few days?), according to comments 54 & 55 on the Chromium issue (posted 2 days ago):
  https://bugs.chromium.org/p/chromium/issues/detail?id=559258#c54

So, if both of those ^ go according to plan, we may not need any compat quirks here & this may end up being WONTFIX.

Comment 7

[Mike Taylor [:miketaylr]]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> So, if both of those ^ go according to plan, we may not need any compat
> quirks here & this may end up being WONTFIX.

That would be awesome.

Comment 8

[Daniel Holbert [:dholbert]]

rbyers says on 3/18:
"A fix for Mobile GMail has now landed for this (but will likely take a week or two to reach production)"
https://bugs.chromium.org/p/chromium/issues/detail?id=559258#c56

Comment 9

[Mike Taylor [:miketaylr]]

Mobile Gmail did fix, and Blink removed this quirk:

https://bugs.chromium.org/p/chromium/issues/detail?id=559258#c59

Looks like the few sites that reported regressions were updated too. 

Adenilson said that Edge has possibly reverted their implementation of the quirk as well. Given that, I say we WONTFIX this (and hope we don't need to re-open one day).