Bug 35479 - SVG fallback color doesn't work for bogus gradients.
Summary: SVG fallback color doesn't work for bogus gradients.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://dev.w3.org/SVG/profiles/1.1F2/...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-27 09:46 PST by Dirk Schulze
Modified: 2010-03-12 12:44 PST (History)
3 users (show)

See Also:


Attachments
Patch (24.26 KB, patch)
2010-02-27 11:49 PST, Dirk Schulze
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Schulze 2010-02-27 09:46:33 PST
fallback color doesn't work for bogus gradients.
Comment 1 Dirk Schulze 2010-02-27 11:49:05 PST
Created attachment 49685 [details]
Patch
Comment 2 WebKit Review Bot 2010-02-27 11:54:16 PST
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.
Comment 3 Dirk Schulze 2010-02-27 11:59:08 PST
(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?
Comment 4 David Levin 2010-03-01 10:29:07 PST
(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()
?
Comment 5 Dirk Schulze 2010-03-01 11:13:05 PST
(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
Comment 6 Eric Seidel (no email) 2010-03-05 15:09:05 PST
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).
Comment 7 Nikolas Zimmermann 2010-03-07 09:48:07 PST
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.
Comment 8 Dirk Schulze 2010-03-12 12:44:49 PST
Comment on attachment 49685 [details]
Patch

Clearing flags on attachment: 49685

Committed r55930: <http://trac.webkit.org/changeset/55930>
Comment 9 Dirk Schulze 2010-03-12 12:44:59 PST
All reviewed patches have been landed.  Closing bug.