712929 - Type Inference breaks certain JavaScript code

Status: RESOLVED DUPLICATE of bug 706808

(Core :: JavaScript Engine, defect)

Description

[Frank Wienberg]

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__.

Comment 1

[Jan de Mooij [:jandem]]

I can confirm the problem with Firefox 9.0.1; testcase works fine with the latest nightly build or with TI disabled.

Comment 2

[Brian Hackett [Laid off!]]

This looks like bug 706808, can you try the workaround in comment 27 there?  This will be fixed in Firefox 10.

Comment 3

[Frank Wienberg]

(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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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!

Comment 5

[Frank Wienberg]

(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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 7

[Frank Wienberg]

(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)?

Comment 8

[Boris Zbarsky [:bzbarsky]]

It probably doesn't matter much in practice, as long as the right people (akeybl and legnitto) are cced on the discussion.