Type: Bug Fix
Affects Version/s: 2.2.0-m3
Fix Version/s: Backlog
Security Level: Public (Public: Anyone can view)
KRAD Feature Area:UIF Component
KAI Review Status:Not Required
KTI Review Status:Not Required
This will be long winded, sorry, but I believe it is important. Found out a couple things yesterday, because I didn't want to leave off where and forget what I was doing. Sending this to everyone, so everyone is aware of the issues we are facing in this area at the moment, please send any ideas you may have after reading through this:
Tested tables outside of krad in an html file WITHOUT use of datatables. When I resize the window with 5-6 tables present on the page which each of width: 100% firefox gets some slow-down just with resizing a page which contains tables only. Chrome resizes quickly with no stuttering.
Then I added datatables to the equation. The result was the same, but may a tiny bit slower nothing noticeable really.
So then I started poking around in the performance of the KRAD page and profiling during the on resize interaction. This caused me to find the lines 542-544 of krad.widget.js createTable method:
So I added this to the custom html page out of the KRAD context, and saw a very small dip in performance. Not anything super noticeable like KRAD, but could see a very small amount of lag in Chrome now.
I investigated why this was added and found
KULRICE-5338 Data table does not resize correctly when page is initially small fixed by Eric Njogu.
Then I removed the above lines in KRAD along with setting the bAutoWidth flag to false in datatable options. This caused some performance improvements but I was still getting quite a bit of lag during the resize. I also tested the above jira without this code now in place to see if the data table would resize correctly when the page was initially small and it still does, so this "fix" is not needed based on my testing and not being able to reproduce the jira condition with the fix removed.
HOWEVER, I was still get that lag, so I did some more profiling and found that for every resize event bubblepopup is doing SOMETHING and I think it is doing this something on each element it is configured for. But, because the code is obfuscated I cannot determine why or what it is doing on resize (my best guess is it is trying to reposition the bubble popups that are shown, so it check for each element they are configured on). This list of elements is pretty massive for this page. So I then tested the generated fields page and the lag was obviously present there (though less so because the page is extremely simple). Seems to get a little more laggy if a tooltip is actually showing (not 100% sure).
So it seems the lag is tied directly to jQuery bubblepopup, haven't worked on any ideas or done further investigation to see if we alleviate or fix this yet, but difficult with the obfuscated code (though we have made modifications directly to the same obfuscated code before by guessing what it did). Also, not sure if there is some bubblepopup setting we can set to stop this from happening (not likely I am turning off most of these automatic features that I can configure in their options).
Then more unrelated investigation:
I wanted to test why the tables were breaking outside of their containing divs when used in stacked sub collections. So I copied the KRAD html and completed removed all our css and only put a border around each stacked item. The problem was still present. What this means is that there is something fundamentally wrong with the layout when using sub collections. After some investigation I found that a table will ALWAYS break out of its containing div if the content it contains is too wide as a general rule in HTML, so its nothing we are doing specifically. So I looked into some solutions:
table display solution in practice:
This is a newer layout option in HTML and from my limited testing it looks to be working in the browsers we plan to support, so we may need to switch over to using this (but not sure if this may cause other breakages) if we want to the div to wrap the inner table content appropriately.
So that is where I am at in my investigation of these table issues, at a place where further investigation of the solutions will take even more additional time so I am halting progress right now on this stuff, but now we at least know the root cause of the issues and MAYBE have some potential solutions to investigate further.