Bug Tracker

Modify

Ticket #7639 (closed bug: duplicate)

Opened 3 years ago

Last modified 3 years ago

.before on same element give unexpected result

Reported by: fddima@… Owned by:
Priority: low Milestone: 1.next
Component: manipulation Version: 1.4.4
Keywords: Cc: john, jeresig, rwaldron, snover, jitter
Blocking: Blocked by:

Description

Calling .before function on same element give unexpected result (element dissapear).

Test case:  http://jsfiddle.net/CeTLt/1/

Change History

comment:1 Changed 3 years ago by addyosmani

  • Cc rwaldron, snover, jitter added
  • Priority changed from undecided to low
  • Status changed from new to open
  • Component changed from unfiled to manipulation

At the moment there are two schools of thought on how this bug should be handled. We can either close as invalid given that the use-case is a paradox which would likely not affect a huge number of users, or we can fix.

I personally feel that this in incorrect usage and should be closed, however there may be valid use-cases which I haven't thought of as yet.

Bare in mind: should we decide to fix this, all manipulation methods may need to be updated to check if they themselves are the target of the manipulation.

Other notes: ajpiano discovered that this works in 1.2.6 but breaks in 1.3. Opening the floor to other thoughts on this.

comment:2 Changed 3 years ago by ajpiano

While this test case does seem a bit curious, we've concluded there are vaguely viable reasons why a user might happen to write something like this, and the behaviour is indeed confounding. Also, interestingly, this code works in jQuery 1.2.6, but breaks in jQuery 1.3 and above. It also breaks with .after();

PS. Thanks addy for making this comment irrelevant while I was in the middle of typing it.

comment:3 Changed 3 years ago by rmurphey

I consider this entirely plausible as well -- while the use case might not be desirable, it doesn't feel at all unreasonable, and the last thing you want happening in this case is for your element to disappear entirely.

It may go without saying, but so far this seems to happen with manipulation methods across the board in 1.4.4. Here's another possibly more plausible test case:

 http://jsfiddle.net/ctej7/1/

Version 1, edited 3 years ago by rmurphey (previous) (next) (diff)

comment:4 Changed 3 years ago by addyosmani

  • Cc john, jeresig added

Our further discussions on this seem to indicate that there is a level of validity to it getting fixed. Our group consensus is that at minimum, elements should not simply 'disappear' as per what was experienced with the original ticket.

Without digging too deeply into the code, we believe that the reason this issue is being caused is because we're internally pulling the element in a fragment and inserting obviously fails since it isn't there anymore and no longer has a parent.

Our current concern is how costly it would be to do the required check across all manipulation methods - we don't *think* it would be too expensive, however we could be wrong. CC'ing John for his input too.

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

comment:5 Changed 3 years ago by fddima

I personally feel that this in incorrect usage and should be closed, however there may be valid use-cases which I haven't thought of as yet.

I catch this bug in real code. Some works about dynamic reordering of elements.

Of course i solve this issue easily by additional checks in my algorithm, but before i assumes, that any DOM manipulations have behavior as described in W3C DOM Level 1/2/3 and i thinking in same terms.

Thanks!

comment:6 Changed 3 years ago by john

  • Milestone set to 1.next

comment:7 Changed 3 years ago by john

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

comment:8 Changed 3 years ago by john

Duplicate of #4087.

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.