Bug 35479 – SVG fallback color doesn't work for bogus gradients.

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Dirk Schulze]

fallback color doesn't work for bogus gradients.

[Dirk Schulze]

Created attachment 49685 [details]
Patch

[WebKit Review Bot]

Attachment 49685 [details] did not pass style-queue:

Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
WebCore/svg/graphics/SVGPaintServer.cpp:129:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
Total errors found: 1 in 9 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Dirk Schulze]

(In reply to comment #2)
> Attachment 49685 [details] did not pass style-queue:
> 
> Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
> WebCore/svg/graphics/SVGPaintServer.cpp:129:  Tests for true/false,
> null/non-null, and zero/non-zero should all be done without equality
> comparisons.  [readability/comparison_to_zero] [5]
> Total errors found: 1 in 9 files
> 
> 
> If any of these errors are false positives, please file a bug against
> check-webkit-style.

I check if the size is zero, negative values are allowed. I had problems with this rule multiple times now, can't we get rid of it?

[David Levin]

(In reply to comment #3)
> (In reply to comment #2)
> > Attachment 49685 [details] [details] did not pass style-queue:
> > 
> > Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
> > WebCore/svg/graphics/SVGPaintServer.cpp:129:  Tests for true/false,
> > null/non-null, and zero/non-zero should all be done without equality
> > comparisons.  [readability/comparison_to_zero] [5]
> > Total errors found: 1 in 9 files
> > 
> > 
> > If any of these errors are false positives, please file a bug against
> > check-webkit-style.
> 
> I check if the size is zero, negative values are allowed. I had problems with
> this rule multiple times now, can't we get rid of it?

Instead of
  item->objectBoundingBox().width() != 0
why can't it just be
  item->objectBoundingBox().width()
?

[Dirk Schulze]

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Attachment 49685 [details] [details] [details] did not pass style-queue:
> > > 
> > > Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
> > > WebCore/svg/graphics/SVGPaintServer.cpp:129:  Tests for true/false,
> > > null/non-null, and zero/non-zero should all be done without equality
> > > comparisons.  [readability/comparison_to_zero] [5]
> > > Total errors found: 1 in 9 files
> > > 
> > > 
> > > If any of these errors are false positives, please file a bug against
> > > check-webkit-style.
> > 
> > I check if the size is zero, negative values are allowed. I had problems with
> > this rule multiple times now, can't we get rid of it?
> 
> Instead of
>   item->objectBoundingBox().width() != 0
> why can't it just be
>   item->objectBoundingBox().width()
> ?

Even if we give a warning for negative values (eg. negative with or height on a rect=, we still render this objects. If I make item->objectBoundingBox().width(), all negative values would cause a stroke of a path with black, insteaf of a gradient. This isn't correct in my opinion. That's why it has to be != 0

[Eric Seidel (no email)]

Comment on attachment 49685 [details]
Patch

Your test case woudl be slightly clearer if the expected result was instead a 100x100 green rect (since that's a common test case expectation to mean pass).

[Nikolas Zimmermann]

Comment on attachment 49685 [details]
Patch

r=me, looks fine. The style issue seems to be okay after Dirks explaination.
@Eric: We can't use a 100x100 rect, after all Dirk is testing 1d objects.

[Dirk Schulze]

Comment on attachment 49685 [details]
Patch

Clearing flags on attachment: 49685

Committed r55930: <http://trac.webkit.org/changeset/55930>

[Dirk Schulze]

All reviewed patches have been landed.  Closing bug.