Skip to main content

Bug Tracker

Side navigation

#12773 closed bug (notabug)

Opened October 20, 2012 07:39PM UTC

Closed October 21, 2012 10:39PM UTC

Last modified January 21, 2013 09:16PM UTC

slideDown() bug changes "display" property of child elements; slideUp does not

Reported by: Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.8.2
Keywords: dbr Cc:
Blocked by: Blocking:

slideDown() changes "display" property of child elements.

This is unwanted! (I am the programmer. I know which element I want to slideDown. If I wanted any child elements to be changed I would call slideDown on them, and I DO .. IF I want the child element shown. The parent is a <UL> list of forum topics, the children are <LI> topic links, some unread, some read. The display or hiding of topics already read, are handled separately from the show all/hide all of the parent <UL>.)

When I call slideUp on the parent <UL> it leaves all the child <LI> elements "display" properties as I have them set (ie, only the unread topics showing.)

This IS expected behavior.

When I call slideDown on the parent <UL>, I expect it, and ONLY it's "display" property to be set "block", which should reveal the list but NOT touch the child items. The list should display as it was when I hid it with slideUp.

PC - Windows XP

Google Chrome 22.0.1229.94

Attachments (0)
Change History (9)

Changed October 20, 2012 08:26PM UTC by dmethvin comment:1

owner: →
status: newpending

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket.

Additionally, be sure to test against the jQuery Edge version to ensure the issue still exists. To get you started, use this boilerplate: Open the link and click to "Fork" (in the top menu) to get started.

Changed October 21, 2012 10:25PM UTC by comment:2

Replying to [comment:1 dmethvin]:

Please provide a complete reduced test case on jsFiddle to help us assess your ticket.

I am sorry, I do not have the time. I need to move forward, so I will be forced to write a workaround, and avoid using the slide functions on parent elements that wrap child elements on which I use slide functions.

It occurs to me that if some coders wanted a slide function that affected all child elements, the Core team should have written a slideAllUp() and slideAllDown() function, instead of having the base functions do this.

It also seems poor practise to have a function that is called on an object, that secretly affects other objects. (The API dictionary makes no mention of the child element effects.)

Changed October 21, 2012 10:39PM UTC by dmethvin comment:3

resolution: → notabug
status: pendingclosed

Sounds like we're pretty bad people for doing whatever we've done. Lacking a test case I'll close this as not being a bug.

Changed January 21, 2013 09:44AM UTC by anonymous comment:4

The tone of the poster is entitled and uncalled for, but this is still a valid bug, even without a test case (which is not really necessary, as a cursory test of the stated steps will reveal that this is a problem).

Changed January 21, 2013 03:06PM UTC by mikesherov comment:5

Sorry anonymous, but a valid bug by definition comes with a test case. If you can reproduce the problem, then provide a test case and this will get reopened.

Changed January 21, 2013 05:20PM UTC by comment:6

I agree, dmethvin's "we're pretty bad people for doing whatever we've done" response was beyond sarcastic, and unhelpful.

I could understand leaving the status as "pending" whilst waiting for a test case to be filed.

But to respond so snottily and resolve the issue as "not a bug" ''when it clearly is a bug'', is a slap in the face. (I have 35+ years engineering experience with at least 30 years using, building and programming computers. jQuery API page(s) asked us to report bugs. I spent valuable the time to do so. Did so in a matter of fact manner. The result was an insult.)

I will not be filing any more bug reports (although I have indeed found more.)

"... ''a valid bug by definition comes with a test case''."

sounds like lawyer-speak, similar to:

"''Death by murder is not a crime, unless you can prove your case''"

Changed January 21, 2013 06:04PM UTC by dmethvin comment:7

I'm not sure what I could do if you didn't want to provide a test case. We get a lot of bug reports and if we took the time to mind-read and determine what someone was talking about it would take even more of our volunteeered time.

I can't tell you how many times I've tried to do that and been told that "Oh I meant it happened in IE7" or "Well it breaks if I use the jQuery-borken plugin." when neither was originally specified. A test case is worth a thousand words.

For example, based on your insistence that this is so amazingly easy to reproduce I tried creating a test case and it doesn't fail:

How much longer should I spend on this ticket? Is there some information you haven't given that would help us to solve this issue? Are the words in your original ticket sufficient to describe the problem? Have I misinterpreted your words? See how difficult this is when someone doesn't provide a test case?

I will not be filing any more bug reports (although I have indeed found more.)

We welcome bug reports with test cases, but you already mentioned you were too busy to provide them. I understand that, it's pretty normal for people to be focused on their own work. But please don't berate us for lack of mind reading skills.

Changed January 21, 2013 08:33PM UTC by rwaldron comment:8

keywords: → dbr

Changed January 21, 2013 09:16PM UTC by rwaldron comment:9


Thanks for the report! I've volunteered to take the time to recreate your issue and have produced irrefutable evidence that this is not a bug: