Type Inference breaks certain JavaScript code

RESOLVED DUPLICATE of bug 706808

Status

()

--
blocker
RESOLVED DUPLICATE of bug 706808
7 years ago
7 years ago

People

(Reporter: frank, Unassigned)

Tracking

9 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0
Build ID: 20111216140209

Steps to reproduce:

Run this JavaScript code (tested in Firefox 9):

function Class() {
  this.field = this.field();
}
Class.prototype = {};
var fields = {
  field: function() {
    return 1;
  }
};
for (var m in fields) {
  Class.prototype[m] = fields[m];
}
alert(new Class().field);


Rationale: We simulate classes with field initializers that are stored as functions on the prototype.


Actual results:

"this.field is not a function" in line 2

Evaluation
========

When the constructor is entered, the "this" object has an "own" property "field" of value "undefined". The __proto__ still contains the initializer function under "field", but it is shaded by the "own" property that magically appeared.

If you leave out line 4 (which shouldn't make any difference), everything works fine.

If you assign "field" directly to Class's prototype (without a loop, which shouldn't make any difference), everything works fine.

If you go to "about:config", switch off "javascript.options.typeinference", and restart Firefox, everything works fine.

You don't need to copy a function from an object literal to reproduce the bug; this is just to illustrate that I did not invent this JavaScript code just to be malicious.

The minimal version of the reproducer that even fits into a tweet is:

function C(){this.x=this.x;}
C.prototype={};
for(var m in {x:0})
  C.prototype[m]=1;
alert(new C().x);

In this version, all correctly working JavaScript engines alert "1", while Firefox 9 with type inference activated alerts "undefined".



Expected results:

An alert should appear, containing "1".

In other words, "this.x" must not be "undefined" when the constructor is entered, but it must inherit the given function from its __proto__.
(Reporter)

Updated

7 years ago
Severity: normal → blocker
I can confirm the problem with Firefox 9.0.1; testcase works fine with the latest nightly build or with TI disabled.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This looks like bug 706808, can you try the workaround in comment 27 there?  This will be fixed in Firefox 10.
(Reporter)

Comment 3

7 years ago
(In reply to Brian Hackett (:bhackett) from comment #2)
> This looks like bug 706808, can you try the workaround in comment 27 there? 
> This will be fixed in Firefox 10.

Workaround works around. But I am not sure if I want to patch the Jangaroo compiler and recompile & redeploy all Jangaroo applications only to make them work in Firefox 9. When was the release date for FF10 again? ;-)
But seriously, is there any chance you will merge the fix into the 9 branch?
One more thing, I would probably have found bug 706808 if it contained the words "type inference" anywhere instead of only "TI"...
And what I learned: as a framework vendor, we have to keep up with your pace and test major Firefox releases *before* they are final.
> When was the release date for FF10 again? ;-)

https://wiki.mozilla.org/RapidRelease/Calendar says January 31.

> But seriously, is there any chance you will merge the fix into the 9 branch?

We could do that, perhaps, but there are no releases planned from that branch anymore, as far as I know, so it wouldn't help...  the code would be in version control, but not in users' hands.  ccing the people who would have a better idea about that.

> and test major Firefox releases *before* they are final.

Yes, please!  If you can test Beta, or even Aurora, that would be incredibly helpful to us!
(Reporter)

Comment 5

7 years ago
(In reply to Boris Zbarsky (:bz) from comment #4)

Thanks for the quick reactions, Brian and Boris!

> > But seriously, is there any chance you will merge the fix into the 9 branch?
> 
> We could do that, perhaps, but there are no releases planned from that
> branch anymore, as far as I know, so it wouldn't help...  the code would be
> in version control, but not in users' hands.  ccing the people who would
> have a better idea about that.

Really, no more 9.0.x updates? My fox just got updated to 9.0.1, so that would mean no updates for the next 5 weeks? I had expected at least one security update...
Anyway, I just pushed a workaround for the Jangaroo compiler, but I am still not happy about all Firefox 9 users seeing broken Jangaroo applications until we recompile and deploy every single one.
> I had expected at least one security update..

We'd normally only do this for critical being-exploited-in-the-wild vulnerabilities or serious bugs that bite a lot of users or websites.  Which aren't planned, of course.  There is no planned security update other than 10.0.
(Reporter)

Comment 7

7 years ago
(In reply to Boris Zbarsky (:bz) from comment #6)
> > I had expected at least one security update..
> 
> We'd normally only do this for critical being-exploited-in-the-wild
> vulnerabilities or serious bugs that bite a lot of users or websites.  Which
> aren't planned, of course.  There is no planned security update other than
> 10.0.

So you are saying if I find a critical security issue in FF9, this bug fix might make it into an ad-hoc security update? Then I should go take a look! ;-)
Well I have to admit that Jangaroo does not yet have a large public user base, but it is used for enterprise applications, so this bug at least bites all CoreMedia partners and customers.
Anyway, should I close this issue as duplicate, or does that further reduce chances that this bug will get fixed in FF9 (since 706808 is already fixed in FF10 and thus closed)?
It probably doesn't matter much in practice, as long as the right people (akeybl and legnitto) are cced on the discussion.
(Reporter)

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 706808
You need to log in before you can comment on or make changes to this bug.