Creating a table (unattached) + show() on the <tr> scrolls fixed element to top

Reported by:	phoeniciansailor@gmail.com	Owned by:
Priority:	undecided	Milestone:	None
Component:	unfiled	Version:	2.0.1
Keywords:		Cc:	mikesherov
Blocked by:		Blocking:

Description

http://jsfiddle.net/pSZKC/

Firefox 21, Mac OS X 10.8

I have a fixed div covering most of the page. If I use jQuery to create a table (including tbody, tr, td) and then use jQuery to show() the tr, the fixed div will jump ("scroll") back to the top.

When running the jsfiddle, load, then scroll down a bit. Click the first button, and the fixed div scrolls to top. Only happens on the first click. Seems to happen at least as far back as jQuery 1.8.0.

You may try the second button just for kicks, it just demonstrates that using regular javascript to perform the same action doesn't jump the fixed div.

Attachments (0)

Change History (4)

Changed May 28, 2013 02:35PM UTC by dmethvin comment:1

owner:	→ phoeniciansailor@gmail.com
status:	new → pending

That fragment you're trying to .show() isn't attached to the document. You know that, right? So the .show() operation doesn't really make sense. You should only hide/show elements that are in the document.

The cause of the jump is that our actualDisplay internal function injects a TR into the document in order to determine the default (natural) CSS display value since it can't tell unless the element is in the document and stylesheets are applied. That process seems to make Firefox reset the scroll position.

Can you describe why your code is trying to show an element not in the document?

Changed May 30, 2013 08:44AM UTC by anonymous comment:2

Thanks, looks like you found the underlying problem, which can now be corrected.

As for the specifics that led me to find this bug : I clone some HTML to use as a template. While unattached I set various show/hide states on elements — including table rows — so as to avoid potential flickering after it's attached. These elements might get revealed later, so I cannot delete them outright. Anyhow, there are work-arounds for my specific case, but the underlying bug is the important thing.

Changed May 30, 2013 06:30PM UTC by dmethvin comment:3

cc:	→ mikesherov
owner:	phoeniciansailor@gmail.com
status:	pending → new

I'm not sure we can fix this. We don't know whether elements in the markup will be shown or hidden by default based on where it is injected and the CSS in effect. That means we can't accurately set the information we need to correctly hide/show the elements later. If you need to do this reliably with detached elements you'd be better off to avoid .hide() and .show() and instead use classes.

Anyone else have opinions? I am starting to think actualDisplay should just be ripped out and we guarantee absolutely nothing for hide/show on detached elements. Right now it kinda sorta works enough for people to think it should, as in this case.

Changed June 12, 2013 08:55PM UTC by timmywil comment:4

resolution:	→ wontfix
status:	new → closed

I agree with Dave, we should leave this as is.

Side navigation