Fix AtomicStringTable lowercase translator.
It was erroneously checking if a candidate entry in the atomic string
table was an existing lowercase version of the provided string by
comparing the two strings for lower-ASCII equality, but this doesn't
imply that the string found in the atomic string table is lowercase
ASCII.
For urgent merging to release branches, this is a minimal fix.
A followup CL will land a more efficient version of this.
Bug: 1138487
Change-Id: I3af7411879ea831c9210e43cee16bca607b51b30
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2480844
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mason Freed <masonfreed@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#818060}
diff --git a/dom/nodes/Element-setAttribute-crbug-1138487.html b/dom/nodes/Element-setAttribute-crbug-1138487.html
new file mode 100644
index 0000000..9aa9ed8
--- /dev/null
+++ b/dom/nodes/Element-setAttribute-crbug-1138487.html
@@ -0,0 +1,22 @@
+<!DOCTYPE html>
+<script src="/resources/testharness.js"></script>
+<script src="/resources/testharnessreport.js"></script>
+<script>
+// Regression test for crbug.com/1138487.
+//
+// It was possible for a non-ASCII-lowercase string to be used when inserting
+// into the attribute collection if a hashtable encountered it during probing
+// while looking for the ASCII-lowercase equivalent.
+//
+// This caused such a string to be illegally used as an attribute name, thus
+// causing inconsistent behavior in future attribute lookup.
+test(() => {
+ const el = document.createElement('div');
+ el.setAttribute('labelXQL', 'abc');
+ el.setAttribute('_valueXQL', 'def');
+ assert_equals(el.getAttribute('labelXQL'), 'abc');
+ assert_equals(el.getAttribute('labelxql'), 'abc');
+ assert_equals(el.getAttribute('_valueXQL'), 'def');
+ assert_equals(el.getAttribute('_valuexql'), 'def');
+}, "Attributes first seen in mixed ASCII case should not be corrupted.");
+</script>
