Context menu unresponsive when webpage contains CSS animations

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using cefclient.exe, load a webpage containing a continuous webkit CSS 
animation (e.g. pulse)
2. Right-click to get the context menu
3. Click an item in the menu

The application doesn't always respond when the menu item is clicked.
It's worse when multi_threaded_message_loop=true in CefSettings.
In multi-threaded mode, the app fails to respond approx. 30% of the time.
With a single-threaded loop, it's more like 5%-10% of the time.

It seems to be worse if there a multiple different animations on the page.

I'm using CEF r181.
I've seen this problem on Windows XP and Windows 7.

Attached is a webpage that will cause the problem.

Original issue reported on code.google.com by powerbf...@gmail.com on 25 Feb 2011 at 4:30

Attachments:

• pulsing-box.html

[GoogleCodeExporter]

With CEF r195, this issue now appears to happen as much in single-threaded mode 
as in multi-threaded mode.
This could be due to the change to USER_TIMER_MINIMUM (see issue 189) making 
the thread busier doing the animations.

Original comment by powerbf...@gmail.com on 3 Mar 2011 at 5:33

[GoogleCodeExporter]

I've found a workaround, but it means bypassing CEF's built-in context menu and 
rolling my own.

I have HandleBeforeMenu send a message to my main window and then return 
RV_HANDLED.

When the main window receieves the message, it creates and displays a 
custom-built context menu (using the Win API functions CreatePopupMenu, 
AppendMenu and TrackPopupMenu).

Original comment by powerbf...@gmail.com on 9 Mar 2011 at 6:50

[GoogleCodeExporter]

Tested using latest r212 and the context menu is showing 100% time, albeit 
there is a problem when you want to hide that context menu, I need to click 3-5 
times before it gets it. Seems like the problem is that these CSS animations 
(in general) are not optimized, in my case on Athlon XP 1800+ it uses 99% of 
CPU, so it's not a big surprise that context menu or other stuff won't work on 
that page.

Original comment by cagret@gmail.com on 28 Mar 2011 at 1:12

[GoogleCodeExporter]

I've never seen it fail to display the context menu, only fail to respond when 
an item in the menu is clicked. I had also guessed that it's because the thread 
is busy doing the animations, but I never thought to check the CPU usage.

Also, I should clarify that the workaround I mentioned above will only work in 
multi-threaded mode (because it shifts the context menu handling into a 
different thread from the animations).

Original comment by powerbf...@gmail.com on 28 Mar 2011 at 3:11

[GoogleCodeExporter]

cagret: How much CPU does Chromium use when running the same animation on your 
Athlon XP 1800+ system?

Original comment by magreenb...@gmail.com on 28 Mar 2011 at 4:51

[GoogleCodeExporter]

-------- Chrome --------

On Chrome the hiding of context menu fails only 10-20% of the time for the 
first click, the second click almost always works and the menu is hidden.

Cpu usage below:

1st chrome process + 2nd chrome process, total
78 + 22, 100
80 + 16, 96
78 + 17, 95
77 + 18, 95
82 + 14, 96
15 + 79, 94
80 + 16, 96
76 + 20, 96
81 + 15, 96
78 + 18, 96
78 + 18, 96
79 + 16, 95
81 + 15, 96
81 + 14, 95
80 + 14, 94
76 + 19, 95
80 + 15, 95
84 + 12, 96
82 + 13, 95
80 + 14, 94
80 + 14, 94
AVERAGE=95.48

The total system CPU usage in Chrome is always 100%.
The missing 4.5% of cpu is used by "System" process.

-------- CEF --------

On CEF the hiding of context menu fails 99% of the time, it needs in most cases 
5-10 clicks to hide the menu.

Cpu usage below:

cefclient.exe process
78
81
79
87
82
82
86
82
84
79
83
81
83
84
85
82
82
83
84
82
AVERAGE=82.45

The total system CPU usage is also always 100%.
The missing 17.65% of cpu is used by "System" process.

Original comment by cagret@gmail.com on 28 Mar 2011 at 5:42

[GoogleCodeExporter]

Your results are what I expected, which is good :-). You list 2 Chromium 
processes; the 1st is probably the renderer (WebKit) process and the 2nd is 
probably the browser process. Comparing Chromium's WebKit process to CEF's 
single process you're seeing similar CPU usage while running the CSS animation. 
Chromium creates the popup menu in the browser process instead of the renderer 
process, which is why Chromium's popup menu shows better responsiveness. This 
is similar to the situation described in comment #4.

So to improve CEF's popup menu responsiveness we have two options.

1. Always create the popup menu on a separate thread. This isn't really an 
option when CEF is running in single-threaded message loop mode because we have 
only the single WebKit/application thread for handling UI-related events.

2. Throttle WebKit CPU usage while showing the popup menu. This would result in 
slower (or paused?) animation while the popup menu is displayed and would also 
apply for WebGL and other renderer tasks that can take significant CPU.

Is everyone OK with #2 from a user experience standpoint?

Original comment by magreenb...@gmail.com on 28 Mar 2011 at 6:10

• Changed state: Accepted

[GoogleCodeExporter]

You mean to "pause" the animation for the whole time the menu is being shown? 
That would mean pausing it for at least 2-3 seconds on average until user 
clicks an item in the menu. If it's about just slowing then that would be fine 
I guess.

What about the 3rd option? In multi-threaded create popup in a seperate thread, 
in single-threaded throttle the webkit cpu.

Original comment by cagret@gmail.com on 28 Mar 2011 at 6:56

[GoogleCodeExporter]

The 3rd option you propose isn't possible internally because CEF has no way of 
posting tasks to the application thread when different from the WebKit thread 
(which is the case with multi-threaded message loop mode). The user can of 
course implement this 3rd option in their application if they don't want the 
WebKit thread throttled.

Original comment by magreenb...@gmail.com on 28 Mar 2011 at 7:02

[GoogleCodeExporter]

I think it's interesting that the context menu never fails to display.
If it was purely a CPU usage issue, I'd expect that to fail as much as the menu 
item selection does.  In both cases, the app is responding to a mouse click 
(right-click to display the menu, left-click to select a menu item). Why would 
this fail in one case and not the other?

I think there's more to this than meets the eye.

I've attached a log of window messages seen while doing context menu stuff.
In this log, "browser" refers to the CEF browser window and "main" refers to 
the main application window (the parent of the browser window).
(I hijacked the browser window's WndProc so that the messages went through my 
main window's WndProc first so I could log them).

The log shows that when the context menu responds to a mouse click, the browser 
window does not see the mouse clicks, but when the context menu is 
unresponsive, the browser window receives the mouse clicks. So, it looks like 
the context menu is sometimes "missing" the mouse clicks and they are falling 
through to its parent (the browser window).

Original comment by powerbf...@gmail.com on 29 Mar 2011 at 6:30

[GoogleCodeExporter]

oops, forgot the attachment....

Original comment by powerbf...@gmail.com on 29 Mar 2011 at 6:31

Attachments:

• contextmenu.log

[GoogleCodeExporter]

is anybody actively working on this issue now ? i think this issue is also 
responsible for interaction delays with the window frame itself (and its menu) 
it often is sluggish or unresponsive when showing any animation (like webgl 
grass demo).

Original comment by mgt...@gmail.com on 26 May 2011 at 12:08

[GoogleCodeExporter]

Use CEF3 for GPU accelerated content.

Original comment by magreenb...@gmail.com on 2 Oct 2012 at 10:21

• Changed state: WontFix

[GoogleCodeExporter]

May be related to http://code.google.com/p/chromium/issues/detail?id=59864.

Original comment by magreenb...@gmail.com on 19 Dec 2012 at 1:43

[GoogleCodeExporter]

Menu responsiveness fixed with a new CefBrowser::SetOSModalLoop method in trunk 
revision 950, 1271 branch revision 951 and 1180 branch revision 952.

Original comment by magreenb...@gmail.com on 19 Dec 2012 at 4:29

• Changed state: Fixed

[GoogleCodeExporter]

Change CefBrowser::SetOSModalLoop to CefSetOSModalLoop because the
functionality is not connected with any particular browser. Done in trunk 
revision 1062, 1364 branch revision 1063, 1271 branch revision 1064 and 1180 
branch revision 1065.

Original comment by magreenb...@gmail.com on 4 Mar 2013 at 11:36

[GoogleCodeExporter]

CefSetOSModalLoop function added in CEF3 trunk revision 1384, 1547 branch 
revision 1385 and 1453 branch revision 1386.

Original comment by magreenb...@gmail.com on 22 Aug 2013 at 5:12