The test layout/reftests/bugs/331809-1.html fails when I minimize the reftest window. It seems to be the first reftest with this behavior, and it would be good to fix it so that reftests can again be run while the window is minimized. In particular: * when the window is not minimized, both the test and the reference have a focus outline on the Cancel button * when the window is minimized, the reference does not have the focus outline (while the test still does), causing a difference between test an reference

After looking at the test, it really seems like this is a bug in our focus code that these would ever behave differently.

Actually, this seems to happen whenever the reftest window doesn't have focus, not just when it's minimized.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081122 SeaMonkey/2.0a2pre] (home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/5d37678a2482 +http://hg.mozilla.org/comm-central/rev/892e9f783d9e) Confirming on SeaMonkey and Windows.

Any progress? This just tripped us up while verifying new slaves were ok, before adding to main pool-of-slaves.

If there were, you'd have seen it here. :-)

I'm consistently running into this failure when running this reftest by itself without changing the focus or minimizing on Linux. Running this reftest alone I also get the following error (only one copy, not two). JavaScript error: , line 0: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "chrome://global/content/bindings/wizard.xml Line: 317"] I was able to reproduce this error message by putting both the test and reference html files into the tabs that load on startup. It just needs to be two distinct files loaded into two tabs, it can be two copies of the test file. It doesn't matter if either one is the showing tab, or some other tab is the showing tab. And the error message only appears on startup, loading the documents after startup doesn't produce it. Based on the error message I put a breakpoint in nsXULCommandDispatcher::GetFocusedElement where it returns NS_ERROR_DOM_SECURITY_ERR and that is indeed where the error message comes from. Here is a backtrace from there. Breakpoint 2, nsXULCommandDispatcher::GetFocusedElement (this=0xae819280, aElement=0xbff2f958) at /src/content/xul/document/src/nsXULCommandDispatcher.cpp:160 160 NS_RELEASE(*aElement); (gdb) bt #0 nsXULCommandDispatcher::GetFocusedElement (this=0xae819280, aElement=0xbff2f958) at /src/content/xul/document/src/nsXULCommandDispatcher.cpp:160 #1 0xb7d1f6b7 in NS_InvokeByIndex_P () from ./libxpcom_core.so #2 0xb6190b90 in XPCWrappedNative::CallMethod (ccx=@0xbff2fb48, mode=XPCWrappedNative::CALL_GETTER) at /src/js/src/xpconnect/src/xpcwrappednative.cpp:2474 #3 0xb619cb8a in XPCWrappedNative::GetAttribute (ccx=@0xbff2fb48) at /src/js/src/xpconnect/src/xpcprivate.h:2322 #4 0xb619c024 in XPC_WN_GetterSetter (cx=0xb0caac00, obj=0xb37c89c0, argc=0, argv=0xae81b050, vp=0xbff2fc88) at /src/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1622 #5 0xb7dc92d6 in js_Invoke (cx=0xb0caac00, argc=0, vp=0xae81b048, flags=2) at /src/js/src/jsinterp.cpp:1365 #6 0xb7dc9855 in js_InternalInvoke (cx=0xb0caac00, obj=0xb37c89c0, fval=-1283671296, flags=0, argc=0, argv=0x0, rval=0xbff301d4) at /src/js/src/jsinterp.cpp:1426 #7 0xb7dc9a25 in js_InternalGetOrSet (cx=0xb0caac00, obj=0xb37c89c0, id=-1295297684, fval=-1283671296, mode=JSACC_READ, argc=0, argv=0x0, rval=0xbff301d4) at /src/js/src/jsinterp.cpp:1489 #8 0xb7dd55b7 in js_GetSprop (cx=0xb0caac00, sprop=0xb17c8350, obj=0xb37c89c0, vp=0xbff301d4) at /src/js/src/jsscope.h:359 #9 0xb7dd5f8c in js_NativeGet (cx=0xb0caac00, obj=0xb37c89c0, pobj=0xb3776ec0, sprop=0xb17c8350, vp=0xbff301d4) at /src/js/src/jsobj.cpp:4237 #10 0xb7dd7363 in js_GetPropertyHelper (cx=0xb0caac00, obj=0xb37c89c0, id=-1295297684, cacheResult=1, vp=0xbff301d4) at /src/js/src/jsobj.cpp:4399 #11 0xb7da6475 in js_Interpret (cx=0xb0caac00) at /src/js/src/jsinterp.cpp:4409 #12 0xb7dc931c in js_Invoke (cx=0xb0caac00, argc=1, vp=0xae81b020, flags=0) at /src/js/src/jsinterp.cpp:1373 #13 0xb7dc9855 in js_InternalInvoke (cx=0xb0caac00, obj=0xb0c38de0, fval=-1328827744, flags=0, argc=1, argv=0xadedc2d0, rval=0xbff303ec) at /src/js/src/jsinterp.cpp:1426 #14 0xb7d67d4b in JS_CallFunctionValue (cx=0xb0caac00, obj=0xb0c38de0, fval=-1328827744, argc=1, argv=0xadedc2d0, rval=0xbff303ec) at /src/js/src/jsapi.cpp:5187 #15 0xb3353ecc in nsJSContext::CallEventHandler (this=0xae8ef070, aTarget=0xb0c2db80, aScope=0xb0c38de0, aHandler=0xb0cbb2a0, aargv=0xae843fc4, arv=0xbff30518) at /src/dom/base/nsJSEnvironment.cpp:2009 #16 0xb33753f1 in nsGlobalWindow::RunTimeout (this=0xb0c2db80, aTimeout=0xae811c00) at /src/dom/base/nsGlobalWindow.cpp:7762 #17 0xb33758ec in nsGlobalWindow::TimerCallback (aTimer=0xae811c40, aClosure=0xae811c00) at /src/dom/base/nsGlobalWindow.cpp:8096 #18 0xb7d0eb1d in nsTimerImpl::Fire (this=0xae811c40) at /src/xpcom/threads/nsTimerImpl.cpp:427 #19 0xb7d0ec4d in nsTimerEvent::Run (this=0xae8490c0) at /src/xpcom/threads/nsTimerImpl.cpp:519 #20 0xb7d0926d in nsThread::ProcessNextEvent (this=0xb6b79740, mayWait=1, result=0xbff30660) at /src/xpcom/threads/nsThread.cpp:510 #21 0xb7cb4102 in NS_ProcessNextEvent_P (thread=0x0, mayWait=1) at nsThreadUtils.cpp:230 #22 0xb4f6a99c in nsBaseAppShell::Run (this=0xb6a554c0) at /src/widget/src/xpwidgets/nsBaseAppShell.cpp:170 #23 0xb4dcf1c4 in nsAppStartup::Run (this=0xb6aadee0) at /src/toolkit/components/startup/src/nsAppStartup.cpp:193 #24 0xb7ebc5d7 in XRE_main (argc=1, argv=0xbff30c24, aAppData=0xb6b06540) at /src/toolkit/xre/nsAppRunner.cpp:3359 #25 0x080498cc in main (argc=1, argv=0xbff30c24) at /src/browser/app/nsBrowserApp.cpp:156 The nsContentUtils::CanCallerAccess call in nsXULCommandDispatcher::GetFocusedElement ultimately gets to nsScriptSecurityManager::IsCapabilityEnabled where the js stack is: 0 [native frame] 1 anonymous(1103) ["chrome://global/content/bindings/wizard.xml":317] this = [object Window @ 0xb176de40 (native @ 0xb1732ff0)] this.addEventListener = [function] this.window = [object Window @ 0xb176de40 (native @ 0xb1732ff0)] this.document = [object XULDocument @ 0xb17a0240 (native @ 0xb171f800)] this.netscape = [object Object] this.XPCSafeJSObjectWrapper = [function] this.XPCNativeWrapper = [function] this.Components = [object nsXPCComponents @ 0xb1798800 (native @ 0xb1798600)] When just loading the reference or test in an existing browser, nsXULCommandDispatcher::GetFocusedElement is never called (by wizard.xml, sessionstore still calls it), but the cancel button still gets focused. wizard.xml sets up an event to set focus on load, and reftests take a snapshot on the load event, so I think we might have a race condition using this particular xul. The initial bug is just any xul not being clipped by an iframe, so it shouldn't be too hard to find something to test that without onload/focus issues.