<brendan> timely: a bug in XPCNativeWrapper, it should not just fwd enumeration to the wrapped jsobject, it should fault in the DOM, etc. (IDL or QI induced) properties that are enumerable my ramblings: // When a content area frame is focused, update the focused frame URL 282 function contentAreaFrameFocus() - 283 { - 284 const focusedWindow = document.commandDispatcher.focusedWindow; - 285 if (focusedWindow.top == window.content) { - 286 gFocusedURL = focusedWindow.location.href; - 287 gFocusedDocument = focusedWindow.document; 288 } 289 } according to venkman, focusedWindow is an XPCNativeWrapper it has a [[Parent]] window but trying to expand [[Parent]] gives: Operation Failed: [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://venkman/content/venkman-records.js :: vr_listprops :: line 854" data: no] same error happens if the code runs it's the unexpected hit either by venkman poking or running line 286 or just focusedWindow.location in venkman (i.e. that's what breaks in normal contexts) static JSBool XPC_NW_GetOrSetProperty(JSContext *cx, JSObject *obj, jsval id, jsval *vp, JSBool aIsSet) // Be paranoid, don't let people use this as another object's // prototype or anything like that. if (!XPCNativeWrapper::IsNativeWrapper(cx, obj)) { return ThrowException(NS_ERROR_UNEXPECTED, cx); i think i'm about to go down that rabbit hole if (!XPCNativeWrapper::IsNativeWrapper(cx, obj)) { 016691fd 85c0 test eax,eax eax = 1 so, i believe that means i really did fall down the rabbit hole ok, what in the world does that rabbit hole mean? // Be paranoid, don't let people use this as another object's // prototype or anything like that. 1.24 <bzbarsky@mit.edu> 2005-07-05 21:03 focusedWindow is supposed to be a window like any other window oddly enough, it only has 2 properties listed in venkman document is one

this is quite likely to be a show stopper for us, we were forced to downgrade builds and i suspect this is the regression that did us in.

The first paragraph of comment 0 should be a separate bug, so we don't lose it if this one is closed or marked INVALID. /be

Isn't this basically bug 301498?

(In reply to comment #3) > Isn't this basically bug 301498? If by "this" you mean the other bug I wanted filed based on my <brendan> comment quoted in paragraph 0 of comment 0, then yes! Thanks. The rest of this is something timeless was going to investigate, to make sure he was not out of date. Reassigning. /be

Timeless, have you had a chance to look into this any further?

Minusing for 1.8b5 - can you re-nom if you get any further?

Timeless: what is this bug about, really? What's a minimal testcase with expected and actual results? Please test after you pick up the fix to 301498, now in on branch and trunk. /be

Also note bug 307005, which modified the "rabbit hole" that timeless seems to be hitting at the end of comment 0 to try to find an XPCNW on the proto chain if the passed-in |this| object wasn't one.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.