Side navigation
#14750 closed bug (fixed)
Opened February 03, 2014 06:32PM UTC
Closed March 21, 2014 02:49AM UTC
$.show() after $.hide() sometimes does not restore the correct display style
| Reported by: | jd | Owned by: | markelog |
|---|---|---|---|
| Priority: | low | Milestone: | 1.11.1/2.1.1 |
| Component: | css | Version: | 2.1.0 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
The docs of $.show() state:
"With no parameters, ... the matched elements will be revealed immediately, with no animation. This is roughly equivalent to calling .css('display', 'block'), except that the display property is restored to whatever it was initially. If an element has a display value of inline, then is hidden and shown, it will once again be displayed inline."
The implementation in function showHide(elements, show) uses a data_priv variable "olddisplay" to remember the old display when hiding elements. This variable is then used to restore the display property when elements are shown.
The current implementation only sets "olddisplay" once in the first call to hide(), and then restores the display using that value in all subsequent calls to show(). If after the first call to hide() the display property was set to another value, then show() will restore display to the unwanted old value.
I illustrated the bug in http://jsfiddle.net/6XG8u/6/
To work correctly showHide() should always store the current display property when hiding elements.
Attachments (0)
Change History (7)
Changed February 03, 2014 06:38PM UTC by comment:1
| owner: | → jd |
|---|---|
| status: | new → pending |
Changed February 03, 2014 07:08PM UTC by comment:2
| status: | pending → new |
|---|
As suggested the JQuery implementation function showHide() should always store the current display property when hiding elements.
Right now it stores the display property only in the first call to hide().
Changed February 05, 2014 06:17AM UTC by comment:3
| component: | unfiled → css |
|---|---|
| owner: | jd → markelog |
| priority: | undecided → low |
| status: | new → assigned |
Change is trivial and it would saves some bytes
Changed February 13, 2014 03:18PM UTC by comment:4
Hi,
This anomaly is very impactful and creates many problems on each element on which this method is invoked (in my project many case histories are skipped).
Set the CSS display property to "inline-block" without taking into account the old value can create many side effects.
Assume that this element should be considered as a block, but compared to other inline elements do not seem to be correct.
Also, in my opinion, you should increase the priority for this bug so that it can be resolved shortly.
Thanks for your attention, I hope for a quick resolution of your problem.
Changed February 14, 2014 10:28AM UTC by comment:5
Furthermore jQuery 1.11 on ie8 adds zoom:1 css style, and I had to come back to old jQuery version. I think this bug is very dangerous so I suggest you to set ticket's priority to blocker!!!
Changed March 13, 2014 02:44AM UTC by comment:6
| milestone: | None → 1.11.1/2.1.1 |
|---|
So the behavior is documented, and to be expected. What resolution would you suggest for this bug?