Community
Participate
Working Groups
Build Identifier: M20100211-1343 If you are using xulrunner 1.9.2 (and likely later ones), and use a mozilla browser in eclipse. Now in the browser if you browse to a page that has some flash content and you right click on the flash content to bring up a context menu, the CPU jumps up to 100% and stays there till the context menu goes away. If the context menu stays for a long time, the responsiveness becomes even slower. This does not happen on prior versions of xulrunners (1.9.1 and prior) This does not happen on firefox version based on xulrunner 1.9.2 Judging by the behavior it seems like the window message handler of the context menu window is running into a quick loop and the messages are not being processed. This may be related to how mozilla has changed the behavior of plugins so that a plugin crash does not crash the browser itself. Reproducible: Always Steps to Reproduce: 1. Use Xulrunner 1.9.2 as the mozilla browser 2. Using a mozilla based browser navigate to a page with flex/flash content 3. Bring up the context menu by right clicking on the flash content 4. CPU is pegged at 100%
To reproduce this issue 1)download and install 1.9.2.x XulRunner Complete instructions: https://developer.mozilla.org/en/xulrunner_1.9_release_notes as Example for windows: -download and extract XulRunner from http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.9.2.12/runtimes/xulrunner-1.9.2.12.en-US.win32.zip -uninstall previous version of XulRunner: From a command prompt, run xulrunner.exe --unregister-global or xulrunner.exe --unregister-user to unregister XULRunner just as you registered it during installation.Remove the XULRunner directory. -install 1.9.2.12 version: open a command prompt and run xulrunner.exe --register-global 2)Download attached eclipse plugin (source) 3)Import it to your workspace and run as eclipse application 4)Press "Ctrl + 3" and open "Mozilla Browser" view. 5)Just opened view will show "http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html" page with flex content. 6) Right click to show context menu.
Created attachment 184112 [details] simple view with SWT.MOZILLA browser
Your kit profiling results: main hot spot (stack trace): org.eclipse.swt.widgets.Display.msgFilterProc(int, int, int) <- takes 20%CPU during UI hang org.eclipse.swt.internal.win32.OS.DispatchMessageW(MSG) <- Main issue takes 80%CPU during UI hang org.eclipse.swt.internal.win32.OS.DispatchMessage(MSG) org.eclipse.swt.widgets.Display.readAndDispatch() org.eclipse.ui.internal.Workbench.runEventLoop(Window$IExceptionHandler, Display)
VTune profiler Top-down tree: Call Stack CPU Time CPU Time:Total Java_org_eclipse_swt_internal_win32_OS_DispatchMessageW 0s 99.7% nsGetServiceByCID::nsGetServiceByCID 2.560s 99.7% nsGetServiceByCID::nsGetServiceByCID 0.971s 34.7% nsGetServiceByCID::nsGetServiceByCID 0.071s 11.9% Java_org_mozilla_xpcom_ProfileLock_release 0.021s 0.3% nsGetServiceByCID is in xul.dll
I've looked into this with SSQ. On my machine showing the context menu pegs the CPU at around 50%, which is still disruptive. And as was initially reported, it happens with xulrunner 1.9.2.x but is fine with earlier versions. Looking at the win32 messages, we see a constant stream of WM_USER+1 and registered message MozFlashUserRelay, while in Firefox we only see the WM_USER+1's. We have a message filter hook (msgFilterProc) in place, but it's not doing anything, so it does not seem to be a problem. We're not sure whether the extra messages are actually related to this problem, because they also come before the context menu is shown and do not peg the CPU then. I'll look in the area of nsGetServiceByCID since comment 4 suggests that it could be involved. This should basically be a registry look-up, and I've confirmed with a reduced Browser implementation that we're not doing anything to hinder this. Perhaps it's being repeatedly invoked for some reason.
(In reply to comment #5) > Looking at the win32 messages, we see a constant stream of WM_USER+1 and > registered message MozFlashUserRelay, while in Firefox we only see the > WM_USER+1's. We have a message filter hook (msgFilterProc) in place, but it's > not doing anything, so it does not seem to be a problem. We're not sure > whether the extra messages are actually related to this problem, because they > also come before the context menu is shown and do not peg the CPU then. The WM_USER + 1 messages are normal. In the Flash player there's an internal timer that fires that message periodically. The player uses it to give time to process animation, deliver ActionScript events, and so on.
Xulrunner is no longer supported. Closing. Please open new bug if you have issues running with supported web engine.
