Skip to main content

Bug Tracker

Side navigation

#4087 closed bug (fixed)

Opened February 06, 2009 01:31PM UTC

Closed December 12, 2012 04:37AM UTC

insertAfter, insertBefore, etc do not work when destination is original element

Reported by: XASD Owned by:
Priority: low Milestone: 1.9
Component: manipulation Version: 1.6b1
Keywords: Cc:
Blocked by: Blocking:

If you do $("#x").insertBefore("#x") element removed entirely from DOM.It seems somehow related to using dom fragments.

Version 1.2.6 of jquery work as expected(preserve element on the same place)+it has "reverse" parameter for domManip() used in "after" method,but 1.3.1 does not have one.Is there logical error here?


Attachments (0)
Change History (23)

Changed February 06, 2009 03:49PM UTC by XASD comment:1

Sorry,I mean $("#x").insertAfter("#x") don't know about insertBefore.

Changed February 07, 2009 02:24AM UTC by dmethvin comment:2

owner: → john

I see what you mean about the documentFragment stuff. Since jQuery.domManip passes in a fragment, jQuery.clean moves #x to the fragment. Later when it gets to the callback in jQuery.after, the original parentNode is gone.

So how did you come up with this case? Is there some more complex code where you end up trying to insert a node after itself?

Changed February 08, 2009 11:08AM UTC by XASD comment:3

<ul id="m">
	<li class="hl">

$("#m div").insertAfter("#m li:first-child div:last-child");//combine in 1


Changed February 22, 2009 06:02PM UTC by XASD comment:4

1.3.2 still not resolved.


Changed February 26, 2009 09:37PM UTC by katbailey comment:5

Just wanted to report that this same issue is causing a problem in Drupal's tabledrag functionality, though in our case it's insertBefore - here's a link to the issue on

Changed April 09, 2010 05:55AM UTC by XASD comment:6

JQuery 1.4.2 bug is still there.

Changed November 10, 2010 12:35AM UTC by dmethvin comment:7

status: newopen

Changed December 13, 2010 02:50AM UTC by snover comment:8

owner: johnXASD
status: openpending

Could you please confirm this bug still exists using the jQuery 0 GIT version of jQuery on jsFiddle? If it does not, please provide a link to the testcase.

Changed December 13, 2010 07:56PM UTC by jitter comment:9

owner: XASDjohn
priority: majorhigh
status: pendingnew

Confirmed in jQuery 0 git (as of c9c9057c4d4097767ca1 / 2010-12-13)

test case

Changed December 13, 2010 07:56PM UTC by jitter comment:10

status: newopen

Changed April 17, 2011 04:59PM UTC by timmywil comment:11

milestone: →

Changed April 17, 2011 04:59PM UTC by timmywil comment:12

component: coremanipulation

Changed July 11, 2011 06:36PM UTC by ajpiano comment:13

priority: highlow
summary: insertAfterinsertAfter, insertBefore, etc do not work when destination is original element

Confirmed in bug triage, dropping priority to low.

Changed July 12, 2011 07:33PM UTC by john comment:14

#7639 is a duplicate of this ticket.

Changed September 05, 2012 03:17AM UTC by mikesherov comment:15

owner: john
status: openassigned

Changed September 05, 2012 03:17AM UTC by mikesherov comment:16

status: assignedopen

Changed November 09, 2012 01:43AM UTC by pbramos comment:17

I'm going to look at this. Here's a fiddle using the above example:

Changed November 15, 2012 05:16AM UTC by pbramos comment:18

I've got a fix for this that is passing my unit tests. I need to expand my tests a bit to cover all the cases.

Changed November 18, 2012 01:18AM UTC by pbramos comment:19

Changed November 28, 2012 01:37AM UTC by pbramos comment:20

Changed December 04, 2012 05:46AM UTC by gibson042 comment:21

milestone: 1.next1.9

Changed December 10, 2012 09:15PM UTC by pbramos comment:22

aaaaaaaand another pull request:


Changed December 12, 2012 04:37AM UTC by Paul Ramos comment:23

resolution: → fixed
status: openclosed

Fix #4087. insertAfter, insertBefore, etc do not work if origin and destination are same element. Close gh-1068.

Changeset: f12611feb43adb2b014eb2183db0713451746aff