Error 2025 occurring when resizing browser window after instantiating htmlbridge view

[ryantodd]

I am getting an Error #2025 ("An internal error has occurred - Error #2025.") when resizing the browser window after instantiating an html-bridge view. This doesn't seem to happen when loading the vSphere client without instantiating the html-bridge.


It seems to occur more reliably if you load the vsphere client to the specific html-bridge view link and then try resizing the browser repeatedly. It seems to happen less often if you load the vSphere client on the non-html-bridge url and then navigate to the html-bridge and resize the window. Furthermore, if you load vSphere to the html-bridge view URL and navigate elsewhere to a non-html-bridge page in vsphere, resizing the window will still trigger the error.


According to what I find online, this error occurs when trying to removeChild is called with a referenced to an object that is not a child of the caller object.


Getting this in the debug console (afraid it doesn;t seem terribly helpful, will try to get some better info):

ArgumentError: Error #2025: The supplied DisplayObject must be a child of the caller.

at flash.display::DisplayObjectContainer/getChildIndex()

at mx.core::Container/getChildIndex()

at mx.core::Application/getChildIndex()

at com.google.code.flexiframe::IFrame/buildContainerList()

at Function/<anonymous>()

at flash.display::DisplayObjectContainer/addChild()

at mx.core::Container/http://www.adobe.com/2006/flex/mx/internal::createContentPane()

at mx.core::Container/createOrDestroyScrollbars()

at mx.core::Container/createScrollbarsIfNeeded()

at mx.core::Container/createContentPaneAndScrollbarsIfNeeded()

at mx.core::Container/validateDisplayList()

at mx.managers::LayoutManager/validateDisplayList()

at mx.managers::LayoutManager/doPhasedInstantiation()

at mx.managers::LayoutManager/validateNow()

at mx.core::Application/resizeHandler()

at mx.core::Application/commitProperties()

at mx.core::UIComponent/validateProperties()

at mx.managers::LayoutManager/validateProperties()

at mx.managers::LayoutManager/doPhasedInstantiation()

at mx.managers::LayoutManager/validateNow()

at mx.core::Application/resizeHandler()

at flash.events::EventDispatcher/dispatchEventFunction()

at flash.events::EventDispatcher/dispatchEvent()

at mx.managers::SystemManager/Stage_resizeHandler()[E:\dev\4.y\frameworks\projects\framework\src\mx\managers\SystemManager.as:3227]

[laurentsd]

Thanks Ryan, I'll look into this.

[ryantodd]

Had any luck looking into this? I was doing some testing this morning, and this is pretty easy to replicate by

• installing and deploying the globalview-html plugin example
• loading the client in the browser
• repeatedly resizing or sometimes just resizing one by dragging the bottom left corner of the browser up and to the left

I also noted this morning that it is very difficult for me to replicate this in Firefox (in limited testing for a few minutes I could not reproduce). On Firefox I am running 12.0.0.77 (debug version). I cannot replicate this in Chrome on my Lubuntu (14.04) VM running the same Chrome Flash plugin version number as my Mac. I can replicate this 100% of the time in Chrome on my Mac/OSX (which is running the Chrome PepperFlashPlayer.plugin on my Mac, version 14.0.0.125), often by resizing just once. Resizing the browser to make the viewport for the app small (1000x600 or less) seems to make this happen even more readily, but is not a requirement for replicating the issue. I'm wondering if there may be some sort of race condition that is getting introduced in the Chrome version of the flash plugin on Mac on the window resize....

thanks again in advance for looking into this!

[laurentsd]

Thanks for the detailed info.  I couldn't reproduce it on my Mac with Chrome but I was using the Flash player debugger version, not the built-in PepperFlashPlayer.  Now I see it without the debugger which makes it harder to debug 😞   I agree that it must be a race condition.

[muratkarslioglu]

Does anyone have additional info on this issue? Any help would be appreciated.


I am able to 100% reproduce it on Chrome/Firefox and IE, I can share more info to troubleshoot if needed.


- Chrome Version 37.0.2062.124 m
- Adobe Flash Player Version: 15.0.0.152


- Firefox 32.0.3
- Shockwave Flash 13.0.0.182

[laurentsd]

This is fixed in the upcoming 6.0 release and the next 5.5 upgrade (post 5.5u2).