Add UseCounter for case-insensitive attribute value selector matching

Source/core/frame/UseCounter.h

 /*
  * Copyright (C) 2012 Google, Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 280 matching lines @@
         DOMImplementationHasFeature,
         DOMImplementationHasFeatureReturnFalse,
         CanPlayTypeKeySystem,
         PrefixedDevicePixelRatioMediaFeature,
         PrefixedMaxDevicePixelRatioMediaFeature,
         PrefixedMinDevicePixelRatioMediaFeature,
         PrefixedTransform2dMediaFeature,
         PrefixedTransform3dMediaFeature,
         PrefixedAnimationMediaFeature,
         PrefixedViewModeMediaFeature,
+        CaseInsensitiveAttrSelectorMatch, // Case-insensitivity dropped from specification.

[Mike West, 2014/01/23 09:22:54]

I'd suggest adding a counter for attribute selectors in general, so that we have
something to compare against. Right now, it'll be tough to answer the question
"What percentage of calls will this change effect?"

[Jens Widell, 2014/01/23 09:38:49]

I'm not 100 % sure how use counters work, but won't this counter alone answer
the question "how many page loads had at least one selector whose behavior would
change?"?  Do we need to know how many page loads were not affected because they
had no attribute selectors vs. how many page loads were not affected because
their attribute selectors were not case-insensitive to begin with, or were but
matched even without case-insensitivity?

I don't mind adding additional use-counters, of course, but I guess they (too)
would carry a slight performance cost in matching attribute selectors.

[Mike West, 2014/01/23 10:08:24]

I'd suggest that there are two relevant numbers:

1. The percentage of total page loads that this change would affect: that's the
number the counter you're adding gives us.
2. The percentage of page loads that contain selectors which would be affected.

If, for example, #1 was 0.002%, but #2 was 100% (low penetration of a feature,
but every use is broken), we might approach it differently than if #2 was 0.02%
(high penetration of a feature, low impact change).

Does that make sense?

[Jens Widell, 2014/01/23 10:27:21]

How would you define 2?  A case-insensitive attribute selector is

 A) parsed in a stylesheet
 B) checked against an element
 C) checked against an attribute value
 D) something else?

Option A would probably be performance neutral, while B/C would increase the
performance impact of this patch somewhat.

         // Add new features immediately above this line. Don't change assigned
         // numbers of any item, and don't reuse removed slots.
         NumberOfFeatures, // This enum value must be last.
     };
 
     // "count" sets the bit for this feature to 1. Repeated calls are ignored.
     static void count(const Document&, Feature);
     static void count(const ExecutionContext*, Feature);
     void count(CSSParserContext, CSSPropertyID);
     void count(Feature);
@@ skipping 35 matching lines @@
 
     void updateMeasurements();
 
     OwnPtr<BitVector> m_countBits;
     BitVector m_CSSFeatureBits;
 };
 
 } // namespace WebCore
 
 #endif // UseCounter_h