Bug Tracker

Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#10227 closed bug (fixed)

$('body').show() does'nt work if body style is set to display:none

Reported by: Jürgen Owned by: Rick Waldron
Priority: low Milestone: 1.8.3
Component: css Version: git
Keywords: Cc: dmethvin
Blocked by: Blocking:

Description

Hi, i'm using jQuery 1.6.2 and $('body').show(); seems to fail if the style of BODY is set to display:none.

I used $('body').toggle() instead but with the same issue. Removing the display:none in the body-style lets work $('body').toggle() fine.

Best regards, Jürgen

Change History (22)

comment:1 Changed 12 years ago by anonymous

if you need to use show() can set body { display:none; } in css style... tested on IE and Chrome...

for firefox i have to do this:

$(window).load(function(){

if($.browser.mozilla)

$('body').css('display','block');

$('body').fadeIn(100);

});

fadeIn() or show() will fail with FF if body is set to display:none...

comment:2 Changed 12 years ago by addyosmani

Cc: dmethvin added
Component: unfiledcss
Priority: undecidedlow
Status: newopen
Version: 1.6.2git

Confirmed: http://jsfiddle.net/drCRZ/2/. Behaviour present in FF6 and below with jQuery edge and 1.6.3 but not in Chrome or IE. CC'ing dmethvin so he can weigh in on whether this is something we want to address.

comment:3 Changed 12 years ago by dmethvin

Confirmed, I am not seeing a problem on Windows with Chrome 13.0.782.220 m, IE 9.0.8112.16421, or Opera 11.51. I *do* see the problem on Firefox 6.0.2, but it goes away if you use bare JS (http://jsfiddle.net/dmethvin/drCRZ/3/) or remove the display: none from the body style (http://jsfiddle.net/dmethvin/drCRZ/4/).

I suspect things are getting muddled because of the display: none, why does it need to be there?

comment:4 Changed 12 years ago by Timmy Willison

Things are muddled because defaultDisplay can't handle a body element for some reason (not sure why yet). Instead of being set to something workable, it is set to undefined, which means the display style just gets set to empty string, which does nothing to override the embedded style. screenshot of breakpoint in defaultDisplay

comment:5 Changed 11 years ago by mikesherov

looks like defaultDisplay is trying to append the element you're trying to show() to body and then extract the display css attribute out of that. I'm guessing that certain browsers dont like appending a new body to a body.

PR for this should be relatively painless... i'm on it.

comment:6 Changed 11 years ago by mikesherov

hmm, or not... still a bit over my head with the iframe fallback.

comment:7 Changed 11 years ago by mikesherov

So, one question I need answered here... is there ever a reason that the defaultDisplay for a BODY tag shouldn't be "block"? I mean, how is a doc rendered different if BODY was "inline"?

If we always assume the defaultDisplay for a BODY tag is "block", this issue is very easily fixed. Otherwise, I have no idea what the hell is going on.

comment:8 Changed 11 years ago by mikesherov

figured it out... so basically, in FF, getComputedValue inside an IFRAME inherits the display of the outer frame.

If the BODY is display:none, than the IFRAME fallback gets appended to the hidden body, and all of the getComputedValue calls inside that IFRAME are display: none.

So this doesn't just effect body.show(), it affects .show() on any element that needs the IFRAME fallback if the BODY is hidden at the time of adding the IFRAME as a fallback.

Testing this was tons of fun... submitting PR now.

comment:10 Changed 11 years ago by mikesherov

Milestone: None1.7.2
Owner: set to mikesherov
Status: openassigned

comment:11 Changed 11 years ago by dmethvin

Keywords: needsdocs added
Resolution: wontfix
Status: assignedclosed

We're going to just document this.

comment:12 Changed 11 years ago by dmethvin

Keywords: needsdocs removed
Resolution: wontfix
Status: closedreopened

comment:13 Changed 11 years ago by dmethvin

Status: reopenedopen

Mistake.

comment:14 Changed 11 years ago by dmethvin

Resolution: wontfix
Status: openclosed

No, we are really closing this. To clarify it only breaks in FF 3.6.

comment:15 Changed 10 years ago by [email protected]

This is still an issue in the latest Firefox versions; in trying to track it down I filed https://bugzilla.mozilla.org/show_bug.cgi?id=797029 . bz's suggestion in comment 7 seems like it's worth trying -- basically, he's suggesting attaching the <iframe> as a child of the <html> element, and not <body>; that will avoid a display: none rule on body throwing things off. This seems to work fine; it correctly finds the default display of body as 'block' even when a display: none rule is in effect on body in the document.

Only change I made was body.appendElement/body.removeChild -> body.parentNode.appendElement/body.parentNode.removeChild in the defaultDisplay() function.

comment:16 Changed 10 years ago by Rick Waldron

Milestone: 1.7.2
Resolution: wontfix
Status: closedreopened

I'll give Boris's suggestion a try...

comment:17 Changed 10 years ago by Rick Waldron

Owner: changed from mikesherov to Rick Waldron
Status: reopenedassigned

comment:18 Changed 10 years ago by Rick Waldron

Resolution: worksforme
Status: assignedclosed

This issue doesn't exist in jQuery 1.8.x

comment:19 Changed 10 years ago by Rick Waldron

Resolution: worksforme
Status: closedreopened

Just kidding, there was a bug in my test.

comment:20 Changed 10 years ago by Rick Waldron

Resolution: fixed
Status: reopenedclosed

body default display is always block. @mikesherov was right and this is the proof. Fixes #10227

Changeset: 60f546acb1c7136092b4fd01cccff052e468cc72

comment:21 Changed 10 years ago by dmethvin

Milestone: 1.8.3

comment:22 Changed 10 years ago by Oleg

Fix #10227 and simplification and optmization of defaultDisplay helper

Changeset: 664d099f9d7e64a43e1e5423a343fdefa5be649f

Note: See TracTickets for help on using tickets.