I'm looking at an issue I can duplicate in IE7 and IE8 with Compatibility View. The page has two WebDataGrids insied a WebGroupBox that is on an UpdatePanel. EnableDataViewState is true. After binding a datasource (DataSet from SQL) to the grids, the iexplorer.exe process shows CPU activity when the page is sitting idle: no user interaction. It never seems to stop: I've waited up to an hour and the process shows CPU activity in TaskMan and ProcExp. Oddly, ProcMon doesn't show any disk, registry, network, or thread IO from the same process. In IE8, if you disable compatibility view the page laods and CPU returns to 0% until you interact with the page. I'm using version 11.1.20111.2158. The same issue occurs on other pages in the application that have WebDataGrid in WebGroupBox on UpdatePanel. Some grids have filtering and other don't but all have EnableDataViewState=True and cell selection. Example ASPX snippet.
="1008px">
>
="server">
="box">
="False"
="True">
No Waves Found
="100%">
/>
="true">
="300px">
="OnRight">
Ticket :
="100">
="clearDropDowns()"/>
Hi dc06663,
I tested your scenario with the markup and exact build number you specified, but I was not able to reproduce the issue. Does this affect the performance of your machine? Can you provide a sample website, which reproduces this issue?
Thank you.
Performance is impacted: some machines spin 25% CPU while the browser is idle: that's why I'm trying to find the fix. Further testing has shown that it is something in my Site.Master and not the child pages with the grids. Site.Master contains a few WebTextEditor (read-only) and a WebDataMenu. Due to a previous IE7 issue with the WebDataMenu (appearing behind grids in child pages when expanded) I added
function IE7ZIndexAdjust() { var div1 = $get('MenuDiv'); if ($util.IsIE7) { div1.style.zIndex = '10'; div1.style.position = 'relative'; }}
<div id="MenuDiv"><ig:WebDataMenu ID="WebDataMenu" runat="server" Width="1015px" GroupSettings-EnableAnimation="False" EnableExpandOnClick="True"><ClientEvents Initialize="IE7ZIndexAdjust" /><GroupSettings Orientation="Horizontal" /></ig:WebDataMenu></div>
I removed the ClientEvents but that did not correct the phantom CPU usage in IE7 mode while the page is idle. I'll start playing with settings in the WebDataMenu but can you look at it too?
FYI, the menu items are built in code-behind using data from SQL. For example:
WebDataMenu.Items.Add(new DataMenuItem {Text = "Functions"});DataSet results = Common.GetDataSetSQL("EXEC [dbo].[SPNAME] '" + sParam + "'");if (results.Tables["TBNAME"].Rows.Count != 0){ foreach (DataRow rowSQL in results.Tables["TBNAME"].Rows) { WebDataMenu.Items[iMenuIndex].Items.Add(new DataMenuItem { Text = rowSQL["Text"].ToString(), NavigateUrl = "/" + sAppRoot + "/" + rowSQL["NavigateUrl"].ToString() }); }}
The attached ASPX wil produce the anomaly on a XP SP3 client.
Hello dc06663,
Thank you for the sample. I was able to reproduce this issue (indeed it seems to occurr only under very specific circumstances).Therefore, I have asked our engineers to examine the matter further. To ensure that it will receive attention, I have logged this behavior in our internal tracking system with a Development ID of 116256. The next step will be for a developer to review my investigation and confirm my findings or to offer a fix, or other resolution.
Your support ticket id regarding this matter is - CAS-94616-LW7TZD. Feel free to continue sending us updates regarding this issue at any time.
You can view the status of the development issue connected to this case by selecting the "Development Issues" tab when viewing this case on the web site.
Please let me know if you need more information.
How do I view this ticket? I don't have any support cases assigned to my logon.
My apologies, your case should be visible now.
Hi,
I'm would like to know if you guys came up with a fix/workaround for this issue. I came across the same scenario using IE with compatibility mode. It's the WebDataMenu that is causing the issue (event/listener). Once I removed the menu off the page, things turned better.
Thanks.
I checked my history and on 8/14/12 confimred I could not reproduce the issue with 11.2.20112.2159. I have since upgraded to 12.1.20121.2209 and there are no reports of the issue occuring. Additionally, we upgraded the impacted users to IE8 and made sure they were not using compatibility mode as the IE8 engine is significantly faster with some operations. That might not be feasible in your environment; however, using the latest SR for you components should resolve the base issue.