Closed Bug 799875 Opened 8 years ago Closed 8 years ago
Global scope polluter does not pollute qualified lookups: window
.id does not return the same thing as get Element By Id or bareword id
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.22 Safari/537.11 Steps to reproduce: Accessed the HTMLElement with its id on window using window[id] Actual results: Not able to access the HTMLElement using window[id] Expected results: Should be able to access the HTMLElement using window[id]
Repqroducible steps 1. Find and extract the attached FF16.rar 2. Open main.htm in Fireofx16 3. Will get two alerts a. [Object HTMLInputElement] -- Used getElementById b. undefined -- Used window[id] In Firefox15, it is working proper.
Attachment #669900 - Attachment mime type: text/plain → application/x-rar-compressed
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/2208b83cc81d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120920023756 Bad: http://hg.mozilla.org/mozilla-central/rev/6a2d1a3556b9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120920042256 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2208b83cc81d&tochange=6a2d1a3556b9 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/d5720a3513ca Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120919112056 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/adab1fdcfe0a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120919112956 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d5720a3513ca&tochange=adab1fdcfe0a Triggered by: Bug 786801
Alice, you wrote the 1st bad build is in FF18, but the user claims it's not working in FF16. Error?
The patch of Bug 786801 was back ported to 16beta and Aurora17
Is this for cross-global access only?
FF14 behaves the same as FF16+: it is only FF15 where the wnd.inp1 returns the object. This makes sense: FF15 was also affected by bug 786801 but not patched (it was already in release). That's not to say that the FF14- and FF16+ behavior is correct (I don't know: is it bz?). I'm stepping through the resolve hook and we are correctly finding the (cross-compartment) calling script and passing JSRESOLVE_QUALIFIED. Taking out the ALLOW_CROSS_COMPARTMENT in js_InferFlags (thereby restoring FF15 behavior) finds no script and thus passes no resolve flags. If this is a bug, it would seem to be on the XPConnect/DOM side, but I'll step through more to see where we diverge.
The resolve is coming through JSRESOLVE_QUALIFIED. Which makes sense, since it is. And the global scope polluter only pollutes unqualified bareword lookups. It looks like this never worked up through fx14, then in fx15 broke because CPG lost the QUALIFIED flag. We fixed that in bug 786801, which is why fx16 has the same behavior as fx14. The only real question is whether we should make the GSP work for qualified lookups. Spec technically says yes, I think.
Assignee: general → nobody
fwiw, I mid-aired with Luke there. I'm not just repeating him! ;)
Summary: Not able access with id but can be accessed using getElementById → Global scope polluter does not pollute qualified lookups: window.id does not return the same thing as getElementById or bareword id
(In reply to Boris Zbarsky (:bz) from comment #8) > The only real question is whether we should make the GSP work for qualified > lookups. Spec technically says yes, I think. JSRESOLVE_QUALIFIED (really all JSRESOLVE_*) delenda est. Qualified versus unqualified is totally unprincipled and really is indicative of a JSAPI design flaw, as this astute comment implicitly points out: http://hg.mozilla.org/mozilla-central/annotate/ec10630b1a54/js/xpconnect/src/XPCComponents.cpp#l3171 The GSP should work the same for all lookups regardless of qualification.
In any case, for purposes of 16, I think we should consider the 15 behavior a regression from all previous releases and wontfix for 16. And probably 17 and 18. Flipping the GSP on for qualified lookups is the sort of thing I'd want a full cycle on.
Whiteboard: [need review][js:p1]
Target Milestone: --- → mozilla19
Please nominate for uplift to Aurora/Beta.
Lack of nom was intentional, per comment 11. I'd too be leery of not having this ride the trains.
Indeed. I don't think we should be uplifting this.
Hello, I bisect a breakage of remote login to my companies site to this changeset: Die erste fehlerhafte Revision ist: Änderung: 110301:c350c6f28dd1 Nutzer: Boris Zbarsky <firstname.lastname@example.org> Datum: Mon Oct 15 14:00:09 2012 -0400 Zusammenfassung: Bug 799875. Make the global scope polluter work even for qualified lookups. r=jst I'm using Fedora 18 and icedtea-web.x86_64 (1.3.1-3.fc18) The remote login via the Juniper SSLVPN software works correctly in Firefox 18 and is broken in Firefox 19. Juniper version is: Juniper SSLVPN release [7.1.0] - build number  build comment [R6] Bisect log: current e7208eeb05dacbba00bdf8e7631c7c0c5e8438a1 bad 5bb309998e7050c9ee80b0147de1e473f008e221 bad 95752d95cf73bde75446ba732d6fcf4387bacbb3 bad acf7f73e8b18d1400d690cda2c2ce470aa081a14 bad 557cfb0bdc396835d11d6d1f62316fbd92df96cf bad 226cb9228a9e005da8769f28e655b3e05df44aac bad a96deba7de41ab066810760a57ba414bb7341fb9 bad c350c6f28dd17652e01908cf38ab82f19029efb7 good fd72dbbd692012224145be1bf13df1d7675fd277 good 1dde5624fc81e8d98c493e6980b3fa80a6e48fa8 good d9e070c062f0dba3d724ec9f7cfc82f151dfd919 good 4e3c9bd6bd60783bd927eb7214c99f7807c83750 good 790a3878f22a8c795a833bc68e5480b895f9e757 good 7703f0ec6770271ae06a9bd2034f898439da4168 good 224fddb79a387bdb46eace136268ead5f7a99ae5 good ae20b1339bd6029664489b1ae7448431ff080464 good e7208eeb05dacbba00bdf8e7631c7c0c5e8438a1 Shall I open a new bug report for this or is this existing bug report okay for tracking this regression?
(In reply to Thomas Meyer from comment #18) > Shall I open a new bug report for this or is this existing bug report okay > for tracking this regression? Yes, file a new bug and add this current bug blocking your new bug, thanks.
You need to log in before you can comment on or make changes to this bug.