Skip to main content

Bug Tracker

Side navigation

#7611 closed bug (invalid)

Opened November 23, 2010 11:46PM UTC

Closed April 01, 2011 01:18AM UTC

Last modified March 13, 2012 08:16PM UTC

insertBefore fails when target is inline and previous non-empty sibling is inline and ends with a line break in Webkit

Reported by: public@grik.net Owned by:
Priority: low Milestone:
Component: manipulation Version: 1.4.4
Keywords: webkit insertBefore Cc: paul.irish
Blocked by: Blocking:
Description

html:

<span>abc<br></span>

<a href="#">link</a>

JS:

$("a").click(function(){

$("span").clone().insertBefore(this);

});

this works, though:

$("span").clone().insertBefore(this);

$("span").clone().insertAfter(this);

maybe it's a Chrome bug, not jQuery

Attachments (0)
Change History (11)

Changed November 23, 2010 11:52PM UTC by public@grik.net comment:1

sorry, did not notice the link to jsFiddle

bug demo (open in Chrome):

http://jsfiddle.net/SZtbk/1/

this works:

http://jsfiddle.net/4Hukj/

Changed November 24, 2010 01:39AM UTC by snover comment:2

_comment0: This is not a jQuery bug. \ \ Criteria: \ \ 1. The inserted element must be an inline element \ 2. The element must be inserted using insertBefore \ 3. The first previous non-empty, non-white-space-only sibling element for the target of the insert must: \ 1. Be inline and \ 2. End with a line break \ \ If all these criteria are met, the inserted elements will not appear in the DOM until another, different DOM manipulation occurs that does not match these criteria.1290562850484022
_comment1: This is not a jQuery bug. \ \ Criteria: \ \ 1. The inserted element must be an inline element \ 2. The element must be inserted using insertBefore \ 3. The first previous non-empty, non-white-space-only sibling element for the target of the insert must: \ 1. Be inline and \ 2. End with a line break \ \ If all these criteria are met, the inserted elements will not appear until another, different DOM manipulation occurs that does not match these criteria (even though the DOM manipulation occurs successfully).1290563426195425
_comment2: This is not a jQuery bug. \ \ Criteria: \ \ 1. The inserted element must be an inline element \ 2. The element must be inserted using insertBefore \ 3. The first previous non-empty, non-white-space-only sibling element of the target of the insert must: \ 1. Be inline and \ 2. End with a line break \ \ If all these criteria are met, the inserted elements will not appear until another, different DOM manipulation occurs that does not match these criteria (even though the DOM manipulation occurs successfully).1290567127135518

This is not a jQuery bug.

Criteria:

1. The inserted element must be an inline element

2. The element must be inserted using insertBefore

3. The first previous non-empty, non-white-space-only, non-text-node sibling element of the target of the insert must:

1. Be inline and

2. End with a line break

4. There must be at least one text node, empty node, or white-space only node between the sibling containing the line break and the target

If all these criteria are met, the inserted elements will not appear until another, different DOM manipulation occurs that does not match these criteria (even though the DOM manipulation occurs successfully).

Changed November 24, 2010 01:55AM UTC by snover comment:3

component: unfiledmanipulation
milestone: 1.5
priority: undecidedlow
summary: insertBefore(this) bug in Chrome when content has <BR>insertBefore fails when target is inline and previous non-empty sibling is inline and ends with a line break in Chrome

Changed December 01, 2010 06:40AM UTC by SlexAxton comment:4

cc: → paul.irish
keywords: → chrome insertBefore
milestone: → 1.5
status: newopen

This seems like a browser quirk we should try and smooth out, but first we'll report it to chrome and see if we can't get it pushed before we can fix it :D

Changed December 01, 2010 06:57AM UTC by SlexAxton comment:5

keywords: chrome insertBeforewebkit insertBefore

temp01 graciously pointed out that this is a webkit bug, not just a chrome-specific bug. He is correct.

Changed December 01, 2010 06:58AM UTC by SlexAxton comment:6

summary: insertBefore fails when target is inline and previous non-empty sibling is inline and ends with a line break in ChromeinsertBefore fails when target is inline and previous non-empty sibling is inline and ends with a line break in Webkit

Changed December 01, 2010 07:36AM UTC by ajpiano comment:7

"temp01 graciously pointed out that this is a webkit bug, not just a chrome-specific bug. He is correct."

He really is a great guy.

Changed December 01, 2010 07:51AM UTC by temp01 comment:8

Changed December 12, 2010 03:20AM UTC by tangerin01@gmail.com comment:9

Replying to [comment:2 snover]:

This is not a jQuery bug. Criteria: 1. The inserted element must be an inline element 2. The element must be inserted using insertBefore 3. The first previous non-empty, non-white-space-only, non-text-node sibling element of the target of the insert must: 1. Be inline and 2. End with a line break (on the ''same'' line) 4. There must be at least one text node, empty node, or white-space only node between the sibling containing the line break and the target If all these criteria are met, the inserted elements will not appear until another, different DOM manipulation occurs that does not match these criteria (even though the DOM manipulation occurs successfully).

Changed April 01, 2011 01:18AM UTC by dmethvin comment:10

resolution: → invalid
status: openclosed

Here is an example that doesn't use jQuery but shows the problem.

http://jsfiddle.net/SZtbk/12/

I agree that this is a webkit bug, and that temp01 really is a great guy. If it were more critical we could work around it but at this point it doesn't seem like a very frequently encountered case.

I'm going to close this and you can track Webkit's progress via the link further up the ticket.

Changed April 01, 2011 07:27AM UTC by public@grik.net comment:11

than you all, nice to see your attention!

does not seem like webkid guys care, unfortunately