It seems that I've come across another issue. I ha...
# doodle
a
It seems that I've come across another issue. I have some UI components that I show/hide depending on the state of the application, and when I show/hide one specific component and then try to drag it, the application freezes. I'm not sure what exactly is causing this, but after some debugging it looks like the problem is here. Somehow some views are ending up in the
pendingBoundsChange
list, but they have been rendered and their size isn't empty, causing an infinite loop.
n
ah. looks like the item(s) are pending a bounds update, but they also never get rendered. let me know if you have a small repro i can use as i work on a fix. also, i was able to repro the
TextField
issue you raised for desktop and will be working on that as well.
👍 2
do you have a simple repro for this issue you can share?
a
I've been trying to make one, but I haven't succeeded yet. The best I can do at the moment is share the entire application.
👍 1
n
can you let me know if the View that is stuck in the layout loop is NOT recursively
visible
? by this i mean if it or any of its ancestors are not
visible
. essentially checking this at the code line you shared from
RenderManagerImpl
. recursively invisible Views are also not rendered. so i’m wondering if yours is in this state. though i haven’t been able to induce it myself with a nested View that changes visibility while it’s being laid out by its parent (parent’s size changing with a drag for example).
a
I was thinking the same thing. The views stuck in the layout loop are recursively
visible
and all have the same parent, but the strange thing is that that doesn't seem to be the only cause. If there's only one view, the problem doesn't occur. I tried using two dummy
Label
s instead, and it looked like the amount of text also changed whether they got stuck in the layout loop. I still haven't pinpointed the actual cause.
n
it’s possible to get stuck in layout loops for sure. for example, a view that changes its own size when it is laid out by its parent can lead to a loop. is this a possibility in your case?
a
I think what's triggering it is that the parent (which was added invisible) has its
visibility
set to false (it's already false), which calls
RenderManager.visibilityChanged
. If I remove the visibility change, the issue doesn't occur.
n
so parent is added invisibly but it has children that are visible? i’d love to create a test case and ensure a fix. so let me know what the setup is so i can try to repro.
interesting, so setting it to false, while it is already false triggers the change notif?
a
Yeah that seems to be the case. I'll investigate further.
👍 1
n
let me know what you find. i’ve kept trying, but still can’t repro.
👍 1
It's a little strange, but it reproduces the error
😮 1
n
thanks for narrowing it down! i’ll take a look.
i tried the gist and it doesn't cause any error/hanging for me. want to make sure i'm not missing anything.
a
Oh you're right. It only causes the app to freeze on desktop. I was testing on desktop only because of faster compile times. (Windows for me)
If I get a chance I can try to reproduce on web as well
n
ok. reproduced it! looks like these views are not recursively visible (they and all their ancestors are visible). this isn't an issue on web b/c they also have zero size, and are removed from the collection in that case. there are 2 reasons for the differences. labels have zero size on web if they have empty strings (looking to fix this). textfields have an ideal size on desktop, but none on web. the solution should be eliminating items from that collection that have zero size or are not recursively visible. i'll test this and let you know.
yep. that fixes the issue. change will be in 0.10.2. sounds like you're not blocked on this though; is that right? thanks again for reporting the bug.
🎉 1