Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#12773 closed bug (notabug)

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

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

Description

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

Change History (9)

comment:1 Changed 7 years ago by dmethvin

Owner: set to Danzoid61@…
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: http://jsfiddle.net/FrKyN/. Open the link and click to "Fork" (in the top menu) to get started.

comment:2 in reply to:  1 Changed 7 years ago by Danzoid@…

Replying to 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.)

comment:3 Changed 7 years ago by dmethvin

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.

comment:4 Changed 7 years ago by anonymous

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).

comment:5 Changed 7 years ago by mikesherov

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.

comment:6 Changed 7 years ago by Danzoid61@…

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"

comment:7 Changed 7 years ago by dmethvin

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:

http://jsfiddle.net/dmethvin/JtDPY/

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.

comment:8 Changed 7 years ago by Rick Waldron

Keywords: dbr added

comment:9 Changed 7 years ago by Rick Waldron

@Danzoid61

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: http://jsfiddle.net/rwaldron/TQscJ/

Note: See TracTickets for help on using tickets.