Skip to main content

Bug Tracker

Side navigation

#10227 closed bug (fixed)

Opened September 08, 2011 10:52AM UTC

Closed October 04, 2012 05:26PM UTC

Last modified September 17, 2013 12:09PM UTC

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

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


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,


Attachments (0)
Change History (22)

Changed September 08, 2011 08:06PM UTC by anonymous comment:1

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:






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

Changed September 09, 2011 09:32AM UTC by addyosmani comment:2

cc: → dmethvin
component: unfiledcss
priority: undecidedlow
status: newopen
version: 1.6.2git

Confirmed: 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.

Changed September 09, 2011 01:10PM UTC by dmethvin comment:3

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 ( or remove the display: none from the body style (

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

Changed September 09, 2011 01:34PM UTC by timmywil comment:4

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

Changed October 14, 2011 12:41PM UTC by mikesherov comment:5

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.

Changed October 14, 2011 12:45PM UTC by mikesherov comment:6

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

Changed October 14, 2011 12:53PM UTC by mikesherov comment:7

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.

Changed October 20, 2011 12:09AM UTC by mikesherov comment:8

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

Changed October 20, 2011 12:10AM UTC by mikesherov comment:9

Changed November 28, 2011 02:36AM UTC by mikesherov comment:10

milestone: None1.7.2
owner: → mikesherov
status: openassigned

Changed December 06, 2011 06:33PM UTC by dmethvin comment:11

keywords: → needsdocs
resolution: → wontfix
status: assignedclosed

We're going to just document this.

Changed December 06, 2011 06:34PM UTC by dmethvin comment:12

keywords: needsdocs
resolution: wontfix
status: closedreopened

Changed December 06, 2011 06:34PM UTC by dmethvin comment:13

status: reopenedopen


Changed December 06, 2011 06:40PM UTC by dmethvin comment:14

resolution: → wontfix
status: openclosed

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

Changed October 04, 2012 12:41AM UTC by comment:15

This is still an issue in the latest Firefox versions; in trying to track it down I filed . 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.

Changed October 04, 2012 03:12PM UTC by rwaldron comment:16

milestone: 1.7.2
resolution: wontfix
status: closedreopened

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

Changed October 04, 2012 03:13PM UTC by rwaldron comment:17

owner: mikesherovrwaldron
status: reopenedassigned

Changed October 04, 2012 04:07PM UTC by rwaldron comment:18

resolution: → worksforme
status: assignedclosed

This issue doesn't exist in jQuery 1.8.x

Changed October 04, 2012 04:49PM UTC by rwaldron comment:19

resolution: worksforme
status: closedreopened

Just kidding, there was a bug in my test.

Changed October 04, 2012 05:26PM UTC by Rick Waldron comment:20

resolution: → fixed
status: reopenedclosed

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

Changeset: 60f546acb1c7136092b4fd01cccff052e468cc72

Changed October 04, 2012 05:29PM UTC by dmethvin comment:21

milestone: → 1.8.3

Changed September 17, 2013 12:09PM UTC by Oleg comment:22

Fix #10227 and simplification and optmization of defaultDisplay helper

Changeset: 664d099f9d7e64a43e1e5423a343fdefa5be649f