Bug 1259348 part 2: Simplify logic in CSSParserImpl::LookupKeywordPrefixAware. r?mats draft
authorDaniel Holbert <dholbert@cs.stanford.edu>
Fri, 03 Feb 2017 14:56:15 -0800
changeset 470545 dcccff4f390e7ee0ef0ae0b733a164759483aeed
parent 470544 3c943aa4edb3b54306514afb8828d485e63f74c3
child 544517 265551c2bb9ccb7273e5875df9ea830f7f594619
push id44072
push userdholbert@mozilla.com
push dateFri, 03 Feb 2017 22:56:34 +0000
reviewersmats
bugs1259348
milestone54.0a1
Bug 1259348 part 2: Simplify logic in CSSParserImpl::LookupKeywordPrefixAware. r?mats MozReview-Commit-ID: D9WoQ9vXTGJ
layout/style/nsCSSParser.cpp
--- a/layout/style/nsCSSParser.cpp
+++ b/layout/style/nsCSSParser.cpp
@@ -7107,75 +7107,46 @@ CSSParserImpl::ParseTreePseudoElement(ns
 #endif
 
 nsCSSKeyword
 CSSParserImpl::LookupKeywordPrefixAware(nsAString& aKeywordStr,
                                         const KTableEntry aKeywordTable[])
 {
   nsCSSKeyword keyword = nsCSSKeywords::LookupKeyword(aKeywordStr);
 
+  if (!sWebkitPrefixedAliasesEnabled) {
+    // Not accepting webkit-prefixed keywords -> don't do anything special.
+    return keyword;
+  }
+
   if (aKeywordTable == nsCSSProps::kDisplayKTable) {
-    // NOTE: This code will be considerably simpler once we can do away with
-    // all Unprefixing Service code, in bug 1259348. But for the time being, we
-    // have to support two different strategies for handling -webkit-box here:
-    // (1) "Native support" (sWebkitPrefixedAliasesEnabled): we assume that
-    //     -webkit-box will parse correctly (via an entry in kDisplayKTable),
-    //     and we simply make a note that we've parsed it (so that we can we
-    //     can give later "-moz-box" styling special handling as noted below).
-    // (2) "Unprefixing Service support" (ShouldUseUnprefixingService): we
-    //     convert "-webkit-box" directly to modern "flex" (& do the same for
-    //     any later "-moz-box" styling).
-    //
-    // Note that sWebkitPrefixedAliasesEnabled and
-    // ShouldUseUnprefixingService() are mutually exlusive, because the latter
-    // explicitly defers to the former.
     if ((keyword == eCSSKeyword__webkit_box ||
          keyword == eCSSKeyword__webkit_inline_box)) {
-      const bool usingUnprefixingService = false;
-      // XXXdholbert This bool^ will be removed & this whole function will be
-      // simplified in the next patch in this series.
-      if (sWebkitPrefixedAliasesEnabled || usingUnprefixingService) {
-        // Make a note that we're accepting some "-webkit-{inline-}box" styling,
-        // so we can give special treatment to subsequent "-moz-{inline}-box".
-        // (See special treatment below.)
-        if (mWebkitBoxUnprefixState == eHaveNotUnprefixed) {
-          mWebkitBoxUnprefixState = eHaveUnprefixed;
-        }
-        if (usingUnprefixingService) {
-          // When we're using the unprefixing service, we treat
-          // "display:-webkit-box" as if it were "display:flex"
-          // (and "-webkit-inline-box" as "inline-flex").
-          return (keyword == eCSSKeyword__webkit_box) ?
-            eCSSKeyword_flex : eCSSKeyword_inline_flex;
-        }
-      }
-    }
-
-    // If we've seen "display: -webkit-box" (or "-webkit-inline-box") in an
-    // earlier declaration and we honored it, then we have to watch out for
-    // later "display: -moz-box" (and "-moz-inline-box") declarations; they're
-    // likely just a halfhearted attempt at compatibility, and they actually
-    // end up stomping on our emulation of the earlier -webkit-box
-    // display-value, via the CSS cascade. To prevent this problem, we treat
-    // "display: -moz-box" & "-moz-inline-box" as if they were simply a
-    // repetition of the webkit equivalent that we already parsed.
-    if (mWebkitBoxUnprefixState == eHaveUnprefixed &&
-        (keyword == eCSSKeyword__moz_box ||
-         keyword == eCSSKeyword__moz_inline_box)) {
+      // Make a note that we're accepting some "-webkit-{inline-}box" styling,
+      // so we can give special treatment to subsequent "-moz-{inline}-box".
+      // (See special treatment below.)
+      if (mWebkitBoxUnprefixState == eHaveNotUnprefixed) {
+        mWebkitBoxUnprefixState = eHaveUnprefixed;
+      }
+    } else if (mWebkitBoxUnprefixState == eHaveUnprefixed &&
+               (keyword == eCSSKeyword__moz_box ||
+                keyword == eCSSKeyword__moz_inline_box)) {
+      // If we've seen "display: -webkit-box" (or "-webkit-inline-box") in an
+      // earlier declaration and we honored it, then we have to watch out for
+      // later "display: -moz-box" (and "-moz-inline-box") declarations; they're
+      // likely just a halfhearted attempt at compatibility, and they actually
+      // end up stomping on our emulation of the earlier -webkit-box
+      // display-value, via the CSS cascade. To prevent this problem, we treat
+      // "display: -moz-box" & "-moz-inline-box" as if they were simply a
+      // repetition of the webkit equivalent that we already parsed.
       MOZ_ASSERT(sWebkitPrefixedAliasesEnabled,
                  "The only way mWebkitBoxUnprefixState can be eHaveUnprefixed "
                  "is if we're supporting webkit-prefixed aliases");
-      if (sWebkitPrefixedAliasesEnabled) {
-        return (keyword == eCSSKeyword__moz_box) ?
-          eCSSKeyword__webkit_box : eCSSKeyword__webkit_inline_box;
-      }
-      // (If we get here, we're using the Unprefixing Service, which means
-      // we're unprefixing all the way to modern flexbox display values.)
       return (keyword == eCSSKeyword__moz_box) ?
-        eCSSKeyword_flex : eCSSKeyword_inline_flex;
+        eCSSKeyword__webkit_box : eCSSKeyword__webkit_inline_box;
     }
   }
 
   return keyword;
 }
 
 //----------------------------------------------------------------------