Bug Tracker

Opened 13 years ago

Closed 13 years ago

#1383 closed bug (worksforme)

Dealing with CSS "auto" values

Reported by: benoire Owned by:
Priority: major Milestone: 1.2.2
Component: effects Version: 1.1.3
Keywords: Cc:
Blocked by: Blocking:

Description

I have a simple animation as follows:

$('#wf-actionrecords-scroll').animate( { left : 0 }, 'slow', 'default', wf_stepNavigateComplete);

This has stopped working in IE6 & IE7 since upgrading to v1.1.3.1 (with no changes having been made to the source code in the process) and I've spent hours tracing through the code to try and find why it's playing up. I've finally tracked it down to the fact that within .fx, IE is reading it's 'left' CSS attribute value as 'auto', and consequently an error is getting thrown on line 2211 where it's trying to parseInt() this value.

To compound the problem, this animation is taking place in the callback function of an AJAX request, meaning that the javascript error was being masked by the try/catch logic within .ajax (lines 1841 - 1870) and rather than the browser raising a javascript error, including a line number etc, it was instead calling the AJAX error function specified when the call was made, which gave no indication of where the problem lay at all. It's only by doing some intensive debugging in Visual Studio that I've been able to step through and eventually track it down.

Having done all this, the simple fix was to set an explicit value of "0" for #wf-actionrecords-scroll, but it seems to me that this shouldn't be necessary, especially as it used to work fine before v1.1.3. What's more, I think the fact that javascript errors occurring within the AJAX callback function are being masked is also an issue that should be dealt with, although I don't know whether this warrants a separate ticket or not.

Having compared v1.1.3.1 to v1.1.2, it seems that there was a check on whether this parseInt() call was valid which no longer exists - line 2100 of the v1.1.2 source.

Change History (1)

comment:1 Changed 13 years ago by davidserduke

Milestone: 1.1.41.2.2
Resolution: worksforme
Status: newclosed

I was unable to reproduce this bug. It has been a while since it was written and I don't even see a parseInt call in fx.js so perhaps it was fixed. I'm going to close it, but please if you are still able to reproduce the problem reopen it with an test case that displays the error.

Note: See TracTickets for help on using tickets.