Opened 11 years ago

Closed 10 years ago

Last modified 7 years ago

#6399 closed defect (fixed)

dojox.fx.highlight tests fail on Safari

Reported by: guest Owned by: nic
Priority: high Milestone: 1.4
Component: Dojox Version: 1.1.0
Keywords: Cc: wolever@…
Blocked By: Blocking:


Instead of fading to the background colour of the object, everything fades to black, then snaps to the correct colour.

This is Safari Version 3.1 (4525.13) on OS X 10.4.11 with Dojo 1.1.0

The test is dojox/fx/tests/test_highlight.html

Attachments (3)

Picture 4.png (17.2 KB) - added by guest 11 years ago.
After fading from yellow to black (as seen here), the bgcolor snaps back to the correct colour.
_base.js.diff (510 bytes) - added by nic 10 years ago.
color.patch (2.3 KB) - added by nic 10 years ago.

Download all attachments as: .zip

Change History (18)

Changed 11 years ago by guest

Attachment: Picture 4.png added

After fading from yellow to black (as seen here), the bgcolor snaps back to the correct colour.

comment:1 Changed 11 years ago by dante

Milestone: 1.2
Owner: changed from Bryan Forbes to dante
Status: newassigned

comment:2 Changed 11 years ago by bill

Component: fxDojox

comment:3 Changed 11 years ago by dante

Milestone: 1.21.4

So I've determined what this is, but want to blame dojo.Color somehow -- though can't figure out where why. Both safari and FF3 report the endColor as being rgba(0,0,0,0), IE7 calls it "transparent", both cases are being checked for already, so the color animation used in safari isn't reading the 0 opacity, and animating to black ( rga(0,0,0) ) ... The internal onEnd handler is setting it back properly, which is why it "works", but yes, is horribly wrong to be going towards black here.

bumping to see if anything else can be determined in core Color class, or perhaps it's even in animateProperty.

comment:4 Changed 11 years ago by dante

(In [14098]) refs #6399 - try setting the background style back to the orig value, which works, and shows this issue is in Color or animateProperty. needs further debugging.

comment:5 Changed 10 years ago by nic

It's not a safari related problem: FF3 reports "transparent" for endColor, safari rgba(0, 0, 0, 0): new dojo.Color("transparent") returns rgba(255, 255, 255, 1), new dojo.Color("rgba(0, 0, 0, 0)") returns rgba(0, 0, 0, 0).

So, FF3 maps transparent to white (and opacity = 1, the default dojo.Color value), safari to black: if you put a black background on your page, FF3 seems to be wrong, not safari.

Finally, animateProperty to an endColor rgba(0, 0, 0, 0) fails in both FF3 and safari, the "opacity" is not properly set (but works!)

comment:6 Changed 10 years ago by nic

The patch fixes the test page, assuming "transparent" == "white" on safari too.

Changed 10 years ago by nic

Attachment: _base.js.diff added

Changed 10 years ago by nic

Attachment: color.patch added

comment:7 Changed 10 years ago by nic

Added a "transparentColor" property to djConfig (eg [255,0,0] maps the "transparent" dojo.Color to red; white is the default)

comment:8 Changed 10 years ago by dante

Owner: changed from dante to nic
Status: assignednew

comment:9 Changed 10 years ago by nic

Status: newassigned

comment:10 Changed 10 years ago by nic

Resolution: fixed
Status: assignedclosed

(In [18795]) fixes #6399 - added a new dojo.config property (transparentColor) to set a default

comment:11 Changed 8 years ago by bill

(In [25750]) Remove duplicate and conflicting definition of "transparent". Add "transparent" to NLS message file. Using [0,0,0,0] for transparent as per the CSS3 Color Module spec, and dojo/tests/colors.js unit test.

Refs #3652, #6399, #13370.

comment:12 Changed 7 years ago by Nick Fenwick

What's the deal with this ticket? This behaviour still seems broken.

I posted on dojo-interest with a link to demonstrating the problem, at least in Chrome. This bug is marked 'fixed', is this a different problem? Should I open a new ticket? I have no 'reopen ticket' option below.

comment:13 Changed 7 years ago by bill

Well, according to this ticket you need to set dojo.config.transparentColor to the appropriate color for your page. Your test case isn't doing that, right? I don't know why the code can't just query the background color of the object itself though.

comment:14 Changed 7 years ago by bill

PS: I guess this is partly due to my [25750] change, but anyway, looks like (short of changing dojox.fx.highlight to automatically figure out the background-color of the object), you need to specify dojo.config.transparentColor.

comment:15 Changed 7 years ago by neekfenwick

@bill ah, you're right, I'm not doing that. I had read that the transparentColor needed was set in one case, in a comment above, but didn't realise that this is required in any page trying to use this behaviour.

This seems one of those very rare cases when dojo needs pre-configuring something, like dojoBlankHtmlUrl. It's not mentioned at all that I can see in the docs

It seems surprising to me, in this day and age of alpha transparencies, that we should have to specify what the 'transparent' colour is .. surely we're not actually using transparency, we're just defining a solid colour that happens to match the background.

So I specify transparentColor: [255,255,255] in my djConfig, as in and it seems to work.. the changeset claims that [255,255,255] is the default yet leaving it out left me with an ugly fade-to-black effect.

I'll look at commenting in the docs that transparentColor must be defined for dojox.fx.highlight to work reliably.

Note: See TracTickets for help on using tickets.