| Issue 772: | CPU hits 100% in Browser process and locks up browser | |
| 10 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Product Version : 0.2.149.27 URLs (if applicable) : www.gametrailers.com Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 3: Firefox 3: IE 7: What steps will reproduce the problem? 1. Open task manager 2. Play an embedded HD video (gametrailers) 3. While the video is playing scroll the page up and down What is the expected result? The page should scroll and normal browser operation should continue What happens instead? CPU utlitization of "Browser" process hits 100% and the browser will hang for approximately 10 seconds, or until a warning pops up saying the tab is not responding. Please provide any additional information below. Attach a screenshot if possible. I'm using a single core CPU (athlon64 2800) |
||||||||||||||||||||||||
,
Sep 16, 2008
This looks like it might be a duplicate of Issue 1087 and Issue 93 (scrolling with a video Plugin pegs the CPU, poor Flash performance, etc.) From the looks of this issue, scrolling seems to be problematic with non-Flash video players as well.
Labels: -Area-Unknown Area-Plugins
|
|||||||||||||||||||||||||
,
Sep 25, 2008
I don't see a 100% spike and lock down of Chrome but definitely Chrome is using more CPU when scrolling compared to other browsers. This might be a dupe of issue 93 or issue 1087 . Leaving it open till they are fixed.
Status: Untriaged
Labels: flash v-153.1 |
|||||||||||||||||||||||||
,
Sep 29, 2008
This only seems to happen on single core machines, where the browser process takes up 100% CPU starving the Flash plugin process (which is running at below normal priority). Pushing up the priority of the Flash plugin process stops this from happening. |
|||||||||||||||||||||||||
,
Sep 29, 2008
Deprecate Area-Plugins label in favor of Area-WebKit and a separate Plugins label (reducing number of Area- labels).
Labels: -area-plugins Area-WebKit Plugins
|
|||||||||||||||||||||||||
,
Sep 30, 2008
(No comment was entered for this change.)
Status: Started
Owner: ana...@chromium.org |
|||||||||||||||||||||||||
,
Sep 30, 2008
This can also be reproduced with the following URL. http://finance.google.com/finance?q=INDEXDJX:.DJI%20INDEXNASDAQ:.IXIC%20INDEXSP: Move around the chart with the left mouse button pressed down. Then click outside on the browser window. |
|||||||||||||||||||||||||
,
Sep 30, 2008
Fixed in revision 2740 This fixes http://code.google.com/p/chromium/issues/detail?id=772, which was an issue with the browser UI thread entering a tight loop at times. The thread inputs of the browser UI thread and the plugin thread are attached due to the parent child relationship between the windows. As a result at times the MsgWaitForMultipleObjectsEx API returns the fact that there are messages in the queue (mouse messages). The subsequent peek fails to return any messages causing us to enter a loop for a while. This also happens when the plugin has capture and just before it releases capture, some mousemoves end up in the browser ui thread causing a tight loop. The fix is to check if there are mouse messages in the queue by invoking GetQueueStatus and attempting to peek them out with PM_NOREMOVE. If this fails we call WaitMessage to block until the next message. The other fix is to return true from ProcessNextWindowsMessage if PeekMessage returns false and there were sent messages in the queue, as this is as expected. This will ensure that we go back up and peek again instead of calling MsgWaitForMultipleObjectsEx again.
Status: Fixed
|
|||||||||||||||||||||||||
,
Sep 30, 2008
issue 387 looks like a dup of this.. |
|||||||||||||||||||||||||
,
Oct 02, 2008
Looks like much better now. I don't see the tab hanging while playing the above trailers (in the original bug report) and scrolling the tab at time. -Venkat.
Status: Verified
Labels: v-154.1 |
|||||||||||||||||||||||||
| ► Sign in to add a comment | |||||||||||||||||||||||||