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: | Danzoid61@gmail.com | Owned by: | Danzoid61@gmail.com |
---|---|---|---|
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
Attachments (0)
Change History (9)
Changed October 20, 2012 08:26PM UTC by comment:1
owner: | → Danzoid61@gmail.com |
---|---|
status: | new → pending |
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 comment:3
resolution: | → notabug |
---|---|
status: | pending → closed |
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 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 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 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:
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.
Changed January 21, 2013 08:33PM UTC by comment:8
keywords: | → dbr |
---|
Changed January 21, 2013 09:16PM UTC by comment:9
@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/
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.