-
Notifications
You must be signed in to change notification settings - Fork 27.4k
cloneLinkingFn sometimes gets an empty clone with multiple slots #16607
Comments
I am confused. Are you using And what exactly is the problem? Is it that the content is not transcluded sometimes (as if the slot was empty)? But the content is always transcluded correctly (i.e. not empty) with 1.7.0? BTW, it might be helpful to have a code example, even if you can't reproduce the problem. |
I'm using ng-transclude. That's exactly the problem we're facing, the content is sometimes not transcluded as if it was empty. The content is always transcluded with 1.7.0 or with 1.7.1 when I revert the changes from the linked commit. |
Sounds like a |
We have a large number of transcluding components and just a few of them use slots. Because it only happens there, chances are it has something to do with slotted transclusion. But it's hard to reproduce. One hour, I get the error after each reload, next hour, the error is gone for 20 reloads. |
Any chance you could try the following and let me know if the problem goes away? -slots[slotName] = compilationGenerator(mightHaveMultipleTransclusionError, slots[slotName].childNodes, transcludeFn);
+slots[slotName] = compilationGenerator(mightHaveMultipleTransclusionError, jqLite(slots[slotName].childNodes), transcludeFn); |
That's great. Thanks for your quick response. I checked it with and without your change more than 10 times and it really seems let the bug go away. Thank you very much! |
Awesome! Thx for getting back. |
DOM nodes passed to `compilationGenerator()` will eventually be wrapped in `jqLite`, when the compilation actually happens. In Firefox 60+, there seems to be a `DocumentFragment`-related bug that sometimes causes the `childNodes` to be empty at the time the compilation happens. This commit works around this bug by eagerly wrapping `childNodes` in `jqLite`. NOTE: The wrapped nodes have references to their `DocumentFragment` container. This is "by design", since we want to be able to traverse the nodes via `nextSibling` (in order to correctly handle multi-element directives). Once the nodes are compiled, they will be either moved to a new container element or the `jqLite` wrapper is release making them eligible for garbage collection. In both cases, the original `DocumentFragment` container should be eligible for garbage collection too. Fixes angular#16607
I submitted #16615. |
I think we should also open a bug report at Firefox about this. |
TBH, I don't feel we have enough details to create a useful bug report. All I know is that Maybe if we knew the exact version it started failing, it might be useful. |
Nope, sorry, I also thought about a bug report at Firefox but I understand the bug even less than you. |
DOM nodes passed to `compilationGenerator()` will eventually be wrapped in `jqLite`, when the compilation actually happens. In Firefox 60+, there seems to be a `DocumentFragment`-related bug that sometimes causes the `childNodes` to be empty at the time the compilation happens. This commit works around this bug by eagerly wrapping `childNodes` in `jqLite`. NOTE: The wrapped nodes have references to their `DocumentFragment` container. This is "by design", since we want to be able to traverse the nodes via `nextSibling` (in order to correctly handle multi-element directives). Once the nodes are compiled, they will be either moved to a new container element or the `jqLite` wrapper is release making them eligible for garbage collection. In both cases, the original `DocumentFragment` container should be eligible for garbage collection too. Fixes angular#16607
DOM nodes passed to `compilationGenerator()` will eventually be wrapped in `jqLite`, when the compilation actually happens. In Firefox 60+, there seems to be a `DocumentFragment`-related bug that sometimes causes the `childNodes` to be empty at the time the compilation happens. This commit works around this bug by eagerly wrapping `childNodes` in `jqLite`. NOTE: The wrapped nodes have references to their `DocumentFragment` container. This is "by design", since we want to be able to traverse the nodes via `nextSibling` (in order to correctly handle multi-element directives). Once the nodes are compiled, they will be either moved to a new container element or the `jqLite` wrapper is release making them eligible for garbage collection. In both cases, the original `DocumentFragment` container should be eligible for garbage collection too. Fixes #16607 Closes #16615
I'm submitting a ...
Current behavior:
Since AngularJS 1.7.1 we sometimes see the following behavior in Firefox (Windows, Mac, Release and Nightly), but not in Chrome.
The content of li is sometimes just empty. Approx. one out of 20 tries. When I do the transclusion this way:
clone is sometimes empty, i.e. length===0, which normally means that I did a
<slota></slota>
.I tried the AngularJS versions 1.7.2, 1.7.1, 1.7.0 and 1.6.10 and it doesn't work with 1.7.2 and 1.7.1. Every other version is just fine.
I checked the changes between 1.7.0 and 1.7.1 and tried to revert them in the 1.7..1 code. When I revert the change from this commitm, everything works as before.
So far, I was unable to reproduce this in a Plunkr.
AngularJS version: 1.7.1+
Browser: [ Firefox both Release and Nightly on Windows and macOS]
The text was updated successfully, but these errors were encountered: