Closed Bug 500691 Opened 13 years ago Closed 13 years ago
.prototype no longer extends native functions
In short, Function.prototype doesn't seem to extend native functions under the window object.
WFM on mozilla-central nightly, built from http://hg.mozilla.org/mozilla-central/rev/92b6868ef3f4 On what release(s) with what exact buildconfig tips is this broken? /be
OSX: Nightly build fails for me (3.6a1, 20090626), as does 3.5b (20090616). Windows: 3.5 (20090624) fails.
these are just base installs, no options changed and I didn't build them myself.
Mark, can you attach the testcase you're using?
Blake said he had a proto-patch that might fix the bug but still needs a good bit of work.
Assignee: jwalden+bmo → nobody
QA Contact: general → general
This is a regression from bug 451154. What happens is that we initialize function and object classes on the *outer* window and (after connecting the inner and outer objects) call XPCWrappedNativeScope::SetGlobal(outer window). This function looks up Function.prototype on the global. Before bug 451154, looking up Function would call the getter nsWindowSH::GetProperty, forwarding the property lookup to the inner window and retrieving the correct value. Now, there is no such getter, and the function is effectively a no-op. I suspect that we can fix this bug by calling ClearScope on the outer window earlier in SetNewDocument.
The comments in the patch should hopefully explain this... Basically, there's a call in XPConnect (XPCWrappedNativeScope::SetGlobal) that looks up Function.prototype and Object.prototype on the global and we were not calling ClearScope in the right spot. A tunnel-vision view of nsGlobalWindow::SetNewDocument with the stuff that mhammond moved out to nsJSEnvironment.cpp inlined looks like: SetNewDocument(): - ClearScope(outer window) - Maybe free inner objects(now-old inner window) * WrapNative(newInnerWindow) - outer window.mInnerWindow = new nsGlobalWindow() 1 ClearScope(outer window) 2 xpconnect->InitClasses(outer window) - Do prototype fixup dance with outer & new inner window * Causes Function and Object to be re-created on the outer window. Before this patch, 1 and 2 above were reversed, meaning that the call to SetGlobal was effectively a no-op.
I'll attach a mochitest tomorrow (out of time tonight).
As above, but with a mochitest.
Comment on attachment 386324 [details] [diff] [review] With mochitest >@@ -1386,16 +1386,17 @@ NS_IMPL_CYCLE_COLLECTION_CLASS(nsJSConte >+ (void)tmp; Why? >+ok(Function===alert.constructor, "alert's constructor is our Function"); Worth it to also check window.Function here? With those nits, looks scary but ok.
Attachment #386324 - Flags: superreview?(bzbarsky) → superreview+
(In reply to comment #15) > >+ (void)tmp; > Why? Otherwise I get a warning, "tmp is not used" there. > Worth it to also check window.Function here? Sure.
Comment on attachment 386324 [details] [diff] [review] With mochitest r=jst, but leave the first hunk out and fix that in the macros in a new bug.
Attachment #386324 - Flags: review?(jst) → review+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Attachment #386324 - Flags: approval126.96.36.199?
Comment on attachment 386324 [details] [diff] [review] With mochitest Approved for 188.8.131.52. a=ss for release-drivers.
Attachment #386324 - Flags: approval184.108.40.206? → approval220.127.116.11+
Can we please get this on 18.104.22.168 ASAP?
Flags: blocking22.214.171.124+ → blocking126.96.36.199-
Verified fixed on trunk and 1.9.1 with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090714 Minefield/3.6a1pre ID:20090714050656 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:188.8.131.52pre) Gecko/20090715 Shiretoko/3.5.1pre ID:20090715031842
You need to log in before you can comment on or make changes to this bug.