flow
flow copied to clipboard
Deep nested flex layouts freeze in Firefox
Description of the bug / feature
We experience bad performance when opening/switching views with deep nested flex layouts in our App. Web page freezes for 5-6 seconds. Profiling shows that Firefox does style recalculations caused by Vaadin context menu. Ok this maybe a problem of Firefox itslef - I have found some old bugs in Firefox bugzilla, which are already closed (maybe not properly solved). But I think it is still worth to optimize Vaadin code as context menu which is not even displayed should not trigger re-layout, styles re-calculation. We have Vaadin 8 application version with the same layout complexity and there are no such problems there,.
Minimal reproducible example
Download attached project, open Firefox problems view in app, open 3 tabs with nesting 8, 2 and 16. Try to switch between tabs. For me I start noticing the delay from nesting level of 12. To me it does not look like very deep nesting. Example is a bit synthentic, In our app I have encounted only six levels but with more complexity on each level.
Expected behavior
5-6 seconds freeze is too much and it is not consistent - sometimes it does no freeze. Ideal would the same performance as in Chrome.
Actual behavior
Profiler shows style recalculations triggered by context menu or menubar (even empty menubar). But sometimes it is just "Gecko" - I do not know what exactly it means in Firefiox.
Versions:
- Vaadin / Flow version: 22.0.0
- Java version: 11
- OS version: Window 10
- Browser version (if applicable): Firefox 91.4.0esr
I couldn't get the freeze to happen on tab changes. Tested 91.4.1.esr and 95.0.1 and I went with the nesting levels 8, 16, 32, 64, 128 where the creation was a bit slow when doing 128 or 256 levels, but changing tabs has no problems.
I'm not quite certain why you would want to nest VerticalLayouts
inside VerticalLayouts
with multiple HorizontalLayouts
in each VerticalLayout
.
It would be much more correct and efficient to have one VerticalLayout
where you add One HorizontalLayout
containing all 4 components (Label
[which should actually be either Text
or Span
], MenuBar
and the buttons), and have a css indent for each with for instance setting the style for the HorizontalLayout
inline like for instance getElement().getStyle().set("margin-left", (level*indentation) + "px");
So as the usage looks like it will in any case generate performance problems and there are better ways to get the same build result with better performance, this ticket will be closed as invalid.
As I said the example is synthentic and it does not reflect exactly the real layout of application. This was the fastest way to get similar freezing effect. There is no reason to close this as we have real problems in real application. I just need to make example more closer to the application. Also it definitely depends on hardware. Ok I will test it in some other environment.
Ok the problem seems to be reproducable only in VDI environment. On real hardware I also cannot reproduce freezing effect. Still strange that Chrome does not have such problems. This is still a problem for us, but not so big.
I would remember that Firefox has always had slowness when rendering elements with deep element hierarchies.
If a the slowness is clearly from a single component then opening a ticket to https://github.com/vaadin/flow-components for it would be better.
One addtion. Firefox does not freeze with setting: accessibility.force_disabled = 1 And in non VDI environment it does not freeze with any setting. Still with dsiabled accessibility seems to be a bit faster.
Closing issue as there is nothing specific that is working wrong.