Bug Tracker

Opened 9 years ago

Closed 9 years ago

#14715 closed bug (invalid)

"Promise" function resetting numbered bullets to zero

Reported by: rik.comery@… Owned by: rik.comery@…
Priority: undecided Milestone: None
Component: unfiled Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:


JSBin Link: http://jsbin.com/iViSIxo/2/watch?html,js,output

Browsers effected: Internet Explorer only (tested in version 9)

Description: Building an accordion plugin, the "Promise" function appears to re-set numbered bullets to zero following animation.

In the JSBin example, follow the steps below in Internet Explorer to re-produce the issue

  • Click the "Heading" 1 text to expand the hidden text for section 1
  • Click the "Heading" 2 text to collapse the section 1 text and expand the hidden text for section 2
  • Click the "Heading 1" text again. The section 2 text contracts, section 1 text expands, but this time the numbered bullets have been reset to zero

Upon removing the surrounding "Promise" method, the problem does not happen.

Change History (4)

comment:1 Changed 9 years ago by scottgonzalez

Owner: set to rik.comery@…
Status: newpending

What exactly do you mean by 'removing the surrounding "Promise" method'? Do you mean removing the entire block of code that runs in the done handler? Because that's a pretty big change that doesn't really have anything to do with promises.

This is a known bug in IE, based on a specific order of DOM operations. You can see that this came up 3 years ago in jQuery UI: http://bugs.jqueryui.com/ticket/6720 and the solution was simply changing the order of the style changes.

This is reproducible even without promises.

comment:2 Changed 9 years ago by anonymous

When I say “removing the surrounding Promise method”, I am referring to my JSBin sample code. Changing


if(!isVisible) {





if(!isVisible) {



… prevents the problem from happening. Obviously I cannot actually do this, but I thought it might highlight that it was the “Promise” that was causing the error. Clearly this is not the case.

As for the solution, the bug ticket from three years ago states the problem is with the addClass() method, and you say I should change the order of the style changes. As you can see from my provided sample code, I am not using the addClass method. I am simply using slideUp() on multiple elements, followed by a slideDown() within a promise. There isn’t much I can change the order on.

Version 0, edited 9 years ago by anonymous (next)

comment:3 Changed 9 years ago by scottgonzalez

The fact that it exists with .addClass() is irrelevant. It's based on the order of style changes. This can be reproduced without jQuery.

comment:4 Changed 9 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Note: See TracTickets for help on using tickets.