Closed Bug 849602 Opened 8 years ago Closed 7 years ago

Javascript window reference: self is randomly not recognized

Categories

(Core :: JavaScript Engine, defect)

16 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: petermad, Unassigned)

References

Details

(Keywords: regression)

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.
Regression range:
m-c
good=2012-07-13
bad=2012-07-14
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6489be1890c0&tochange=0602e44ac248
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 19 Branch → 16 Branch
Bobby, bug 771202 is in that range; how insane would it be to try to blame you? :)
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
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Hmm.  Window is not on new bindings yet, so it's surprising that the DOM change would have affected any of this stuff...
Flags: needinfo?(efaustbmo)
Flags: needinfo?(bhackett1024)
Flags: needinfo?(bhackett1024)
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?
Flags: needinfo?(petermad)
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
Flags: needinfo?(petermad)
Which Gecko version does SeaMonkey 2.17.1 use?  That is, what is the number after "rv:" in the user-agent string?
Flags: needinfo?(petermad)
SeaMonkey 2.x.y corresponds to Gecko/Firefox (x+3).0.y.
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.
I can also reproduce it in Firefox 21.0
Flags: needinfo?(petermad)
Flags: needinfo?(efaustbmo)
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. :)
Of the things in there, but 792215 looks most likely, if the jspropertyop stuff is broken somehow....
(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?
Flags: needinfo?(bzbarsky)
Depends on: 792215
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?
Flags: needinfo?(bzbarsky) → needinfo?(bent.mozilla)
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.
Flags: needinfo?(bent.mozilla)
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....
Flags: needinfo?(bent.mozilla)
Since it's all going to be WebIDL-ified someday soon I wouldn't worry about it.
Flags: needinfo?(bent.mozilla)
I can confirm that the bug is gone in Seamonkey 2.20 and FireFox 23.0 :-)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.