Bug Tracker

Opened 7 years ago

Closed 6 years ago

#13951 closed bug (wontfix)

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

Reported by: phoeniciansailor@… 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.

Change History (4)

comment:1 Changed 7 years ago by dmethvin

Owner: set to phoeniciansailor@…
Status: newpending

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?

comment:2 Changed 7 years ago by anonymous

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.

comment:3 Changed 7 years ago by dmethvin

Cc: mikesherov added
Owner: phoeniciansailor@… deleted
Status: pendingnew

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.

comment:4 Changed 6 years ago by timmywil

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.