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 getElementById or bareword id

Categories

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

16 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19
Tracking Status
firefox16 + wontfix
firefox17 + wontfix
firefox18 + wontfix
firefox19 + fixed

People

(Reporter: satyacbit, Assigned: bzbarsky)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Attached file FF16.rar (obsolete) —
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.
Severity: normal → critical
Priority: -- → P1
Attachment #669900 - Attachment mime type: text/plain → application/x-rar-compressed
Severity: critical → normal
Priority: P1 → --
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
Assignee: nobody → general
Blocks: 786801
Status: UNCONFIRMED → NEW
Component: Untriaged → JavaScript Engine
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
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?
Attached file Loadable testcase
Attachment #669900 - Attachment is obsolete: true
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
Component: JavaScript Engine → DOM
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.
No longer blocks: 786801
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: [js:p1] → [need review][js:p1]
Attachment #670848 - Flags: review?(jst) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/c350c6f28dd1
Flags: in-testsuite+
Whiteboard: [need review][js:p1]
Target Milestone: --- → mozilla19
https://hg.mozilla.org/mozilla-central/rev/c350c6f28dd1
Assignee: nobody → bzbarsky
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
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.
Depends on: 843075
Depends on: 845882
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 <bzbarsky@mit.edu>
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?
(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.
Depends on: 854890
Depends on: 701672
Duplicate of this bug: 602381
Depends on: 1271135
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.