Bug 697699

Needs triage. The only other time I've seen this was on browser resizing

FF version 3.6.16
OS = Fedora 14

Same issue here:

Firefox 4, osx and linux.
No FF extensions were running at the time.

1 specific location where this type of hang occurred is:  mixed group, summary view, adding portlets

i'm seeing this on chrome as well. I spent several hours with speedtracer in chrome and xul profiler in FF to debug this, this is what I saw:

1) it was easier to replicate on chrome
2) in FF, the resource : alerts portlet listgrid danced (column resized continually) and was a sign of CPU getting pegged
3) in chrome, I used speedtracer to see that when CPU pegged, there was a lot of timer triggers happening that looked to be refreshing the listgrid.
4) in chrome, the CPU issue was never seen if the list grid was *NOT* empty. If I deleted all the empty portlets, CPU went back to normal. 
5) Alert>History uses the same view/table/datasource as the portal and I saw CPU issues there too
6) I changed the list grid widths so that one had "*" width - didn't help
7) I changed the list grid widths so they all were hardcoded (no "*" and no percentages) - didn't help

I saw this now too:

- removing the empty recent alert portlet did not help, so I removed the mashup 
portlet and cpu usage went down

- I added the recent alert portlet again (which was added to the narrower left 
column). This was constantly trying to find to optimal size for the columns.

Created attachment 493806 [details]
Video that shows the resizing (use vlc to view)

Additional data points:
- putting the recent ops portlet to the left has no issues, it puts a big horizontal scrollbar at the bottom and is ok.
- the recent alert portlet on the left does not put a big scrollbar at the bottom, but tries to find the optimal size (which fails, see above)

With mazz to determine the width incantations which don't cause a CPU spike.
Will consider turning off setWidth() calls, and therefore equalizing all column widths, but will probably need to store column width preferences for users too then.

Looks like this problem stems from a single setting on the list grid. In the Table class, if I comment out the setting of setAutoFitData, I didn't see the CPU problem:

        if (flexRowDisplay) {
            //listGrid.setAutoFitData(Autofit.HORIZONTAL); // do NOT set this - smartgwt appears to have a problem that causes it to eat CPU
            listGrid.setWrapCells(true);
            listGrid.setFixedRecordHeights(false);
        }

Created attachment 494995 [details]
snapshot.png

commit 62875f0

one thing that this change now does, is it appears that the listgrid sometimes doesn't resize itself to full 100% width of its parent component (I don't see how this could be related, but this started happening after this commit).

The listGrid does have setWidth100() called, as well as its parent, so I don't know why this happens. See the attached image.

several things to test - do these on both Firefox and Chrome:

1) go to a resource's Summary>Activity page where there are no alerts or operations in the recent alerts/operations portlets
2) shrink the height of the browser window so it cuts in half the size of the right-top portlet
3) hit F5

Make sure the CPU doesn't max out (use "top" or some other tool to do this).

4) Now resize the browser back to a normal size. Hit F5 to refresh the entire app again.
5) Go to the recent alerts and recent operations portlets and increase the width of one or more columns so the entire width of all columns is greater than the width of the listgrid itself.

Make sure the CPU doesn't max out.

this was verified as part of rhq 4.0 and 4.0.1 community releases

Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.