wcx6298 / smartgwt

Automatically exported from code.google.com/p/smartgwt
0 stars 0 forks source link

Deeply nested components trigger IE "stack overflow" bug - have to break up rendering #483

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I extend ListGrid with EditableGrid,then add a EditableGrid in a Tab.
When I remove the Tab from a tabSet. The IE error msgbox with 'Stack overflow 
at line: 0' appear.

GWT2.03
SmartGWT2-2
Downloaded from:http://www.smartclient.com/builds/smartgwt/2010-06-19/

What steps will reproduce the problem?
1.Extend ListGrid
I override the method named createRecordComponent and
   add return ImgButton in the method.

2.New a Tab and add a EditableGrid instance into the Tab.
  Canvas cv = ne Canvas();
  EditableGrid egrid = new EditableGrid();
  ..
  cv.add(egrid);
  Tab tab = new Tab("new tab");
  tab.setCanClose(true);
  tab.addPane(cv);

3.bind some data to the EditableGrid.like this:
  editableGrid.setData(...)

4.When a close the tab page in IE(6/7)
  The error appeared.See the image.

The point is when I added some ImageButton in ListGrid cell.
The Tab couldn't be closed rightly in IE

Original issue reported on code.google.com by Herist.Z...@gmail.com on 7 Jul 2010 at 3:20

Attachments:

GoogleCodeExporter commented 9 years ago
Can this please be addressed? It is a more generic problem than the summary 
suggests. http://code.google.com/p/smartgwt/issues/detail?id=311 has a test 
case at the bottom that reproduces the issue even on nightly builds. This 
problem has been shrugged off in the forums too. Can we at least have some 
disclosure on whether it will ever be fixed?

Original comment by chad.r...@gmail.com on 14 Dec 2010 at 6:53

GoogleCodeExporter commented 9 years ago
As explained on the forums, this second and unrelated problem is an arbitrarily 
imposed native stack depth limit in IE - SmartGWT doesn't go into an infinite 
loop, but IE stops execution at an arbitrary stack depth like 150.  GWT appears 
to be exacerbating the issue by burning extra stack frames.  It's likely to go 
away with future version of IE and/or GWT with no changes to SmartGWT.

It is easily worked around by deferring drawing of interior components of a 
page (just use DelayedCommand), which is better user experience anyway, since 
they will see the basic page framing (outermost layouts) sooner.

Original comment by smartgwt...@gmail.com on 14 Dec 2010 at 10:13

GoogleCodeExporter commented 9 years ago
See above comment. Use DeferredCommand to workaround the issue.

Original comment by sanjiv.j...@gmail.com on 20 Dec 2010 at 12:19

GoogleCodeExporter commented 9 years ago

Original comment by smartgwt...@gmail.com on 10 Jan 2011 at 7:18

GoogleCodeExporter commented 9 years ago
Issue 562 has been merged into this issue.

Original comment by charles....@gmail.com on 14 Mar 2011 at 7:44