Skip to main content

Bug Tracker

Side navigation

#7397 closed bug (fixed)

Opened November 04, 2010 04:02AM UTC

Closed December 14, 2010 06:41AM UTC

Last modified March 09, 2012 09:48PM UTC

Regression: fadeIn no longer works correctly for inline elements

Reported by: dmuir Owned by: rwaldron
Priority: low Milestone: 1.5
Component: effects Version: 1.4.3
Keywords: Cc: john
Blocked by: Blocking:
Description

I just upgraded from 1.4.2 to 1.4.3, and it looks like a bug similar to #4173 is back.

Example: http://jsfiddle.net/Gad7W/22/

When the span is absolutely positioned, the first time you click, it works correctly, but the second time you click, the span has display: block;

If you have FireQuery installed in Firefox, you can see the olddisplay value swap from inline to block when the animation completes.

Attachments (0)
Change History (18)

Changed November 04, 2010 05:24AM UTC by snover comment:1

component: unfiledeffects
milestone: 1.51.4.4
owner: → snover
priority: undecidedblocker
status: newassigned
version: 1.4.31.4.4rc

Changed November 04, 2010 05:44AM UTC by snover comment:2

owner: snover
status: assignedopen

I’m punting on this one.

jQuery.css retrieves the computed style of any given element. In this case the computed style is block as per CSS 2.1 §9.7. Unfortunately it seems using this as the display value changes the way in which the element ends up rendering itself, even though the computed value is the same no matter whether it is specified to be inline or block. Needs more spec research.

Changed November 04, 2010 06:27AM UTC by dmuir comment:3

_comment0: If I'm reading the spec right, it seems that jquery is doing the right and that: \ {{{ \ element {position: absolute;} \ }}} \ should be interpreted as: \ {{{ \ element {display: block; position: absolute;} \ }}} \ \ I guess the problem stems from browsers not following the spec correctly? \ 1288852061078823

If I'm reading the spec right, it seems that jquery is doing the right thing and that:

element {position: absolute;}

should be interpreted as:

element {display: block; position: absolute;}

I guess the problem stems from browsers not following the spec correctly?

Changed November 04, 2010 11:17AM UTC by jitter comment:4

I suspect this may have something to do with this commit #5646a4.

Probably the value of olddisplay, if already set, shouldn't be always ignored as oldisplay does hold inline but gets overwritten with jQuery.css( this[i], "display" ) which is block at that moment.

Changed November 08, 2010 10:45PM UTC by john comment:5

owner: → john
status: openassigned

Changed November 09, 2010 11:10PM UTC by rwaldron comment:6

_comment0: https://github.com/jquery/jquery/pull/901289344339856464

Changed November 10, 2010 04:18AM UTC by rwldrn comment:7

resolution: → fixed
status: assignedclosed

Fixes #7397; Adds 4 supporting unit tests.

Changeset: 795e880bba1f7f949df58748f7fd92e50296a8f4

Changed November 10, 2010 03:49PM UTC by rwaldron comment:8

cc: → john

Updated Unit tests (with original patch)

https://github.com/jquery/jquery/pull/94

( Unit tests are passing in IE 6,7,8 )

Changed November 10, 2010 03:54PM UTC by john comment:9

resolution: fixed
status: closedreopened

Changed November 10, 2010 03:55PM UTC by john comment:10

priority: blockerlow
resolution: → wontfix
status: reopenedclosed

This commit was backed out last night, here: http://bit.ly/cJZckd It's not working correctly across all platforms.

In thinking about this more - this is really something that we're unlikely to fix. If you have an element that is being absolutely positioned it must be display: block (according to the CSS specification). Attempting to make it 'inline'. The fact that you're setting 'inline' (and use to get that value back) was purely incidental (and likely a bug on our end). The change in your code is as simple as making sure that your absolutely positioned elements have a display of 'block' set to them, consistently (this will help your display across browsers, as well).

Changed November 10, 2010 04:19PM UTC by john comment:11

milestone: 1.4.41.4.5
resolution: wontfix
status: closedreopened
version: 1.4.4rc1.4.3

Rick got his patch working - we're going to try this for 1.4.5. Considering that this is handling a weird spec edge case I wouldn't consider this to be a blocker for 1.4.4.

Changed November 10, 2010 04:19PM UTC by john comment:12

status: reopenedassigned

Changed November 19, 2010 09:34AM UTC by snover comment:13

#7563 is a duplicate of this ticket.

Changed November 21, 2010 10:27PM UTC by snover comment:14

owner: johnrwaldron

Changed December 09, 2010 07:12PM UTC by rwaldron comment:15

Changed December 14, 2010 06:41AM UTC by Colin Snover comment:16

resolution: → fixed
status: assignedclosed

Fixes #7397.

Changeset: 2defa4863a114358e03dbae1b10521555fd9cd9c

Changed January 06, 2011 05:47PM UTC by rwaldron comment:17

#7886 is a duplicate of this ticket.

Changed January 14, 2011 10:20PM UTC by jitter comment:18

milestone: 1.4.51.5

Move fixed tickets to appropriate milestone