Bug 62492 – box-shadow rendered differently from Firefox with negative spread

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Alex Yaroshevich]

Created attachment 96824 [details]
Render example for FF5, Chrome and Opera

The man said opera and chrome are not right.

http://dbaron.org/log/20110225-blur-radius
https://bugzilla.mozilla.org/show_bug.cgi?id=655580

Because he does update box-shadow property to the newest spec. But chrome and opera doesn't.

Where is the truth? Looks like he's right after reading spec.

[Alexey Proskuryakov]

The attachment is a link to an image. Could you please attach (not link to) your test case?

[Alex Yaroshevich]

Created attachment 96853 [details]
box-shadow render diff between webkit and gecko

Yep. Sorry. I thought tracker will download it.

[Alex Yaroshevich]

Created attachment 96854 [details]
testcase

Test-case for Webkit. I don't know how it can be tested).

[Alex Yaroshevich]

Oops. It looks equals but it's because hack.
Diff in spread-radius: -8px for webkit and -12px for gecko.
But for positive numbers: 8px for webkit and 6px for gecko (or 12px for webkit and 8px for gecko).

It's very strange.

[Alex Yaroshevich]

That's not only if spread is negative. I'm sure.
I must recalculate spread-radius for pretty now by algo:
  If spread > 0 then firefox-spread = spread*3/2;
  Elseif spread < 0 then firefox-spread = spread*2/3;
But if FF is doing render as told in spec I could say chrome-and-opera-radius ;-) and could do inversion of calculations.

Box-shadow render with spread-radius == 0 is fine (almost equal). And don't if spread is not eq to zero. Afaik.

[Simon Fraser (smfr)]

I don't get what you're saying. Please just make a simple statement of what you think the bug is.

[Brent Fulgham]

Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.