Closed Bug 849602 Opened 8 years ago Closed 7 years ago
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
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
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...
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?
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
Which Gecko version does SeaMonkey 2.17.1 use? That is, what is the number after "rv:" in the user-agent string?
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
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?
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.
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....
Since it's all going to be WebIDL-ified someday soon I wouldn't worry about it.
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.