Bug 261656 - [SVG2] Allow leading and trailing whitespace in svg attributes using <integer>, <angle>, <number>, <length> and <percentage>
Summary: [SVG2] Allow leading and trailing whitespace in svg attributes using <integer...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Karl Dubost
URL:
Keywords: BrowserCompat, InRadar
Depends on: 267560
Blocks:
  Show dependency treegraph
 
Reported: 2023-09-17 12:39 PDT by Ahmad Saleem
Modified: 2024-05-25 06:11 PDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ahmad Saleem 2023-09-17 12:39:28 PDT
Hi Team,

This is another Blink's commit, where we are failing test cases:

Blink Commit: https://src.chromium.org/viewvc/blink?view=revision&revision=175785

Test Case (svg/parser/whitespace-number.html) - https://jsfiddle.net/34nqh1uy/show

Test Case (svg/parser/whitespace-length.html) - https://jsfiddle.net/34nqh1uy/1/show

and there are others as well.

^ We are failing lot of these tests on WebKit ToT as well. Chrome Canary 119 and Firefox Nightly 119 both pass these test case.

Just wanted to raise so we can track it.

Thanks!
Comment 1 Karl Dubost 2023-09-20 02:30:28 PDT
The test:

data:text/html,<svg id="testcontainer"><defs><marker></marker><stop></stop><filter><feTurbulence></feTurbulence></filter></defs></svg>


document.getElementsByTagName('stop')[0].setAttribute('offset', '-47a')


Then they try to 
document.getElementsByTagName('stop')[0].getAttribute('offset')

which returns '-47a' in all browsers.

Where it differs is when requesting:
document.getElementsByTagName('stop')[0].offset.baseVal 

it returns 

-47 in Safari 
0   in Firefox
0   in Chrome

It seems Safari is normalizing the value by ignoring the trailing garbage.
While the others are saying bad values let's reset it.

In fact
document.getElementsByTagName('stop')[0].offset returns on Safari.

{animVal: -47, baseVal: -47}


https://svgwg.org/svg2-draft/pservers.html#GradientStopAttributes
the initial value is indeed 0.
The values

<number>
A number usually ranging from 0 to 1.
<percentage>
A percentage usually ranging from 0% to 100%.


I don't remember where are the processing rules for the invalid values in CSS. 

But baseVal and animVal are defined in
https://svgwg.org/svg2-draft/types.html#__svg__SVGAnimatedString__baseVal
Comment 2 Karl Dubost 2023-09-21 19:15:11 PDT
Related(?) to
https://searchfox.org/wubkat/rev/f997a9edb80cd79caeb1d0a1b87610ffd7a56e88/Source/WebCore/svg/SVGStopElement.cpp#53-63

It converts to float but doesn't to check if the input value if the value looks like a float before converting it to a float. 

The patch from Chromium contains a parseNumber 
https://src.chromium.org/viewvc/blink/trunk/Source/core/svg/SVGParserUtilities.cpp?annotate=175785&pathrev=175785#l230


I wonder if it exists in WebKit?
Comment 4 Karl Dubost 2023-09-21 19:38:43 PDT
So Chris Dumez helped me understand better


    WTF_EXPORT_PRIVATE float toFloat(bool* ok = nullptr) const;

So we could do something like

bool success = false;
float result = attribute.toFloat(&success);
if (success)
   // use result.
else
  // ...
Comment 5 Karl Dubost 2023-09-21 21:27:35 PDT
Ahmad, I think I have a patch for this. It needs a bit more work but It's passing a lot more tests.
Comment 6 Karl Dubost 2023-09-21 22:16:16 PDT
OK My patch gets all green for 
Test Case (svg/parser/whitespace-number.html) - https://jsfiddle.net/34nqh1uy/show



Now let's see the other. :) 
Test Case (svg/parser/whitespace-length.html) - https://jsfiddle.net/34nqh1uy/1/show
Comment 7 Radar WebKit Bug Importer 2023-09-24 12:40:14 PDT
<rdar://problem/115963075>