It seems that the Unicode code point of this character is defined incorrectly in RenderMathMLOperator.cpp.
The issue here seems to be that there are two vertical bars in Unicode ‖ (U+2016) and ∥ (U+2225). We don't handle the latter, which is the one that happens to be in the mathematical section, so we can trivially add support.
Created attachment 215691 [details] Patch
<rdar://problem/15394014>
Created attachment 216050 [details] Patch for EWS
Comment on attachment 216050 [details] Patch for EWS r=me
If the EWS bots looks good, I think this should be landed.
I need to update Mac results since the test itself changed, unless you want to do it in another commit after the patch lands. Either way is fine with me. :)
Comment on attachment 216050 [details] Patch for EWS Attachment 216050 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/21158042 New failing tests: mathml/presentation/mo-stretch.html
Created attachment 216052 [details] Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-12 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Comment on attachment 216050 [details] Patch for EWS Attachment 216050 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/20608058 New failing tests: mathml/presentation/mo-stretch.html
Created attachment 216054 [details] Archive of layout-test-results from webkit-ews-06 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 216056 [details] Re-Upload of Patch with Mac Baseline
Created attachment 216525 [details] Rebased patch for Mac results
Comment on attachment 216525 [details] Rebased patch for Mac results r=me
Committed r159219: <http://trac.webkit.org/changeset/159219>
I've been working on bug 99620 and stretch-mo is the only remaining failing test after my local changes. ∥ (U+2225) has a very confusing entity name, its Unicode name is actually "PARALLEL TO", that's an infix operator ("X is parallel to Y") not a delimiter. The MathML operator dictionary says it is not stretchy and not a fence. Unfortunately, some people have used that character as a delimiter, instead of U+2016. So I'm wondering if we really want to make it stretchy... (IIRC, that's what Gecko does)...
(In reply to comment #16) > I've been working on bug 99620 and stretch-mo is the only remaining failing test after my local changes. ∥ (U+2225) has a very confusing entity name, its Unicode name is actually "PARALLEL TO", that's an infix operator ("X is parallel to Y") not a delimiter. The MathML operator dictionary says it is not stretchy and not a fence. > > Unfortunately, some people have used that character as a delimiter, instead of U+2016. So I'm wondering if we really want to make it stretchy... (IIRC, that's what Gecko does)... Correct me if I'm wrong, but the operator dictionary just specifies the default value of the stretchy operator. The user can still override that by setting the stretchy attribute equal to true. I believe it's up to the user agent what operators stretch in that case. Perhaps the test should just have stretchy=true added to the parallel to operator.
(In reply to comment #17) > Correct me if I'm wrong, but the operator dictionary just specifies the default value of the stretchy operator. The user can still override that by setting the stretchy attribute equal to true. I believe it's up to the user agent what operators stretch in that case. Perhaps the test should just have stretchy=true added to the parallel to operator. Yes, that's correct. I think we can add stretchy=true in the test if we really want to keep it stretchable. And I can add two stretchy prefix/postfix forms for that operator, for people who use that as open/close fences.