Bug Tracker

Modify

Ticket #7611 (closed bug: invalid)

Opened 3 years ago

Last modified 15 months ago

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

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

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

Change History

comment:1 Changed 3 years ago by public@…

sorry, did not notice the link to jsFiddle

bug demo (open in Chrome):  http://jsfiddle.net/SZtbk/1/

this works:  http://jsfiddle.net/4Hukj/

comment:2 follow-up: ↓ 9 Changed 3 years ago by 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
  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).

Last edited 3 years ago by snover (previous) (diff)

comment:3 Changed 3 years ago by snover

  • Priority changed from undecided to low
  • Summary changed from insertBefore(this) bug in Chrome when content has <BR> to insertBefore fails when target is inline and previous non-empty sibling is inline and ends with a line break in Chrome
  • Component changed from unfiled to manipulation
  • Milestone 1.5 deleted

comment:4 Changed 2 years ago by SlexAxton

  • Cc paul.irish added
  • Keywords chrome insertBefore added
  • Status changed from new to open
  • Milestone set to 1.5

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

comment:5 Changed 2 years ago by SlexAxton

  • Keywords webkit added; chrome removed

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

comment:6 Changed 2 years ago by SlexAxton

  • Summary changed from insertBefore fails when target is inline and previous non-empty sibling is inline and ends with a line break in Chrome to insertBefore fails when target is inline and previous non-empty sibling is inline and ends with a line break in Webkit

comment:7 Changed 2 years ago by ajpiano

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

comment:8 Changed 2 years ago by temp01

He has reported the bug to WebKit:  https://bugs.webkit.org/show_bug.cgi?id=50315

comment:9 in reply to: ↑ 2 Changed 2 years ago by tangerin01@…

Replying to 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).

comment:10 Changed 2 years ago by dmethvin

  • Status changed from open to closed
  • Resolution set to invalid

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.

comment:11 Changed 2 years ago by public@…

than you all, nice to see your attention! does not seem like webkid guys care, unfortunately

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.