849602 - Javascript window reference: self is randomly not recognized

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Peter Madsen]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16
Build ID: 20130217195808

Steps to reproduce:

On page http://madsenworld.dk/test/PHSM-CalendarErr.htm if I click the triangle to the lower left of the Flash clock several times consecutively (5-20) the page stops responding to clicking the triangle.



Actual results:

I get this message in the error concole:
Error: TypeError: self is undefined
Source File: http://madsenworld.dk/test/PHSM-CalendarErr.htm Line: 213


Expected results:

It should not fail as it does not do it in this page: http://madsenworld.dk/test/PHSM-Calendar.htm where the only difference is that I use location.protocol in stead of self.location.protocol in line 213 in the page.

If use window.location.protocol I don't get any error either.  I have tested the page in Firefox, Seamonkey, Internet Explorer, Opera, Google Chrome and Safari - and it is only Firefox and Seamonkey that shows this behaviour.

Comment 1

[Loic]

Regression range:
m-c
good=2012-07-13
bad=2012-07-14
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6489be1890c0&tochange=0602e44ac248

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Bobby, bug 771202 is in that range; how insane would it be to try to blame you? :)

Comment 3

[Alice0775 White]

Regression window(cached m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6cd5f16a8c3c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120712182104
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/0c1f34eb5b93
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120712204304
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6cd5f16a8c3c&tochange=0c1f34eb5b93

Suspected: Bug 766447

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hmm.  Window is not on new bindings yet, so it's surprising that the DOM change would have affected any of this stuff...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.  I can't reproduce this anymore; presumably one of the other JIT fixes fixed it?

Peter, do you still see the bug here in a current nightly?

Comment 6

[Peter Madsen]

I still see the bug in SeaMonkey 2.17.1

I am an ordinary user, so I don't use nightly builds - only final releases - sorry

Comment 7

[Boris Zbarsky [:bzbarsky]]

Which Gecko version does SeaMonkey 2.17.1 use?  That is, what is the number after "rv:" in the user-agent string?

Comment 8

[Masatoshi Kimura [:emk]]

SeaMonkey 2.x.y corresponds to Gecko/Firefox (x+3).0.y.

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK, so 20.0?  That's a whole security update behind...

In any case, I can reproduce in Firefox 20 and Firefox 21, but not in a current nightly.

Comment 10

[Peter Madsen]

I can also reproduce it in Firefox 21.0

Comment 11

[Loic]

Working range
bad=2013-04-02
good=2013-04-03
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aae004a3c5d9&tochange=97cfc16ba5dc

No idea about the bug that fixed it but it's fixed since FF23. :)

Comment 12

[Boris Zbarsky [:bzbarsky]]

Of the things in there, but 792215 looks most likely, if the jspropertyop stuff is broken somehow....

Comment 13

[Jan de Mooij [:jandem]]

(In reply to Boris Zbarsky (:bz) from comment #12)
> Of the things in there, but 792215 looks most likely, if the jspropertyop
> stuff is broken somehow....

Can we remove the jspropertyop code from the JITs now, or is perf still a concern?

Comment 14

[Boris Zbarsky [:bzbarsky]]

At this point neither quickstubs nor WebIDL bindings use JSPropertyOps.  I think workers might still use them... Not sure to what extent we should care about that from the JIT pov (as in, whether the relevant worker APIs are performance-sensitive).  Ben?

Comment 15

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Hm, an MXR search for JSPropertyOp shows that it's used in several places in DOM but nowhere in workers... But I'm not sure if that really answers the question.

Comment 16

[Boris Zbarsky [:bzbarsky]]

The relevant question isn't whether the string "JSPropertyOp" is used; its use (typically in a cast) usually denotes that JSPropertyOps are _not_ being used.

The relevant question is whether functions with the signature of a JSPropertyOp are being used.  That signature is:

  JSBool foo(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>,
             JS::MutableHandle<JS::Value>)

For example, in workers code Event::sProperties has properties like this, as does Event::sStaticProperties, DOMException::sProperties, DOMException::sStaticProperties, etc, etc.  The question is whether any of that stuff is performance-sensitive enough that we need to keep JIT ICs for it.  I guess ImageData might be until we nuke the worker-specific ImageData....

Comment 17

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Since it's all going to be WebIDL-ified someday soon I wouldn't worry about it.

Comment 18

[Peter Madsen]

I can confirm that the bug is gone in Seamonkey 2.20 and FireFox 23.0 :-)