799875 - Global scope polluter does not pollute qualified lookups: window.id does not return the same thing as getElementById or bareword id

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[satya]

Attachment: FF16.rar

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]

Comment 1

[satya]

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.

Comment 2

[Alice0775 White]

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

Comment 3

[Loic]

Alice, you wrote the 1st bad build is in FF18, but the user claims it's not working in FF16. Error?

Comment 4

[Alice0775 White]

The patch of Bug 786801 was back ported to 16beta and Aurora17

Comment 5

[Boris Zbarsky [:bzbarsky]]

Is this for cross-global access only?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Loadable testcase

Comment 7

[Luke Wagner [:luke]]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

fwiw, I mid-aired with Luke there.  I'm not just repeating him!  ;)

Comment 10

[Jeff Walden [:Waldo]]

(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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Make the global scope polluter work even for qualified lookups.

Comment 13

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c350c6f28dd1

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c350c6f28dd1

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Please nominate for uplift to Aurora/Beta.

Comment 16

[Jeff Walden [:Waldo]]

Lack of nom was intentional, per comment 11.  I'd too be leery of not having this ride the trains.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Indeed.  I don't think we should be uplifting this.

Comment 18

[Thomas Meyer]

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 <[e-mail]>
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 [20169] 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?

Comment 19

[Loic]

(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.