You can clone with
No one assigned
from the discussion https://groups.google.com/d/topic/angular/F6rG5VbgEpI/discussion:
for the jquery-mobile-angular-adapter I have the following problem in 1.0rc1:
The ng-repeat directive just appends one entry behind the last entry (using element.after).
However, when jquery mobile enhances the page after angular, it wraps the elements into new parents:
E.g. from it creates
With the current ng-repeat this becomes the following after two consecutive $digest cycles:
This is the case as angular's compiler does not know about the new parent-element for the 'a' elements.
Here is a jsfiddle:http://jsfiddle.net/V8a34/1/
From looking into the code of ng-repeat:
Problem is, that the element, to which the cursor in ng-repeat points, is wrapped into another element by jquery mobile. By this, cursor.after() is at the wrong dom hierarchy...
Sure, for my problem this could be fixed just by ensuring in the ng-repeat loop that the cursor is at the same dom hierarchy as the iterStartElement. However, in the general case, when someone would move the create element somewhere else in the dom, this would no more work...
Maybe ng-repeat could leave a comment node as cursor for the next changes, assuming no one moves comment nodes around?
I think I'm having a similar but different problem with directives:
I have a custom directive for jquery chosen and tiny-mce. The way both of these work is they hide the element in question, and generate a new block of html immediately after the element. They then proceed to move around this block doing whatever to setup their plugin accordingly.
I have been getting issues specifically with timing where the plugins will throw some variant of 'undefined' errors when trying to traverse themselves. I believe the reason may be because Angular is in fact removing the elements from the dom during refreshes, and then injecting them back in. Of course, this is merely a guess and I could be completely wrong. But I think if an element is generated using elm.after() (in the plugin), perhaps while the original element is outside the page dom, and then an attempt is made to reselect it, it returns undefined since it can't find the new element it just created outside the document's dom scope.
Thoughts? Perhaps we need a way to 'resize' the focus of a directive after initialization? Or perhaps make sure siblings are properly handled/relocated when the dom is injected/ etc?
I think a better way to solve this is to patch the widgets that wrap themselves into new element.
One should do a precompile that does the wrapping before the actual angular compile. The instantiation of the widget should then no more wrap the element.
Such a precompilation could be done using a decorator for $compile. This works well except for directives that use a templateUrl and use such wrapping directives in the markup that gets loaded. I created a separate issue for that #1001.
So for me, this issue here does not need to be solved any more.
This is really old. If it's still an issue, I'd be happy to re-open this for discussion.