Closed Bug 813952 Opened 12 years ago Closed 3 years ago

console.log access results in a error.

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
17 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox17 --- affected
firefox18 - affected
firefox19 - ---
firefox20 - ---

People

(Reporter: gjohnson, Unassigned)

Details

(Keywords: regression, reproducible) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11

Steps to reproduce:

When running my JavaScript web engine I've things have stopped working in the later version of Firefox (version 12 was ok but I recently tested 16 and things have really screwed up).

Running Firefox in safe mode works just fine.

I've tried disabling ALL extensions in Firefox and have tried running this again but the error persists.

I'm using Windows 7 64-bit.

After looking at the errors in more depth, I noticed that console.log seems to be the problem. It seems to apply to any web page and not just my own JavaScript Application ones.

1. Start Firefox in standard mode.
2. Open scratch pad and type 'console.log("hi");'.



Actual results:

When running my JavaScript application engine, I get the following errors in the Error Console...

Timestamp: 21/11/2012 13:13:59
Error: NS_ERROR_FACTORY_NOT_REGISTERED: Factory not registered
Source File: https://static.login.persona.org/v/b51acfc298/production/en/dialog.js
Line: 6

Timestamp: 21/11/2012 13:15:48
Error: NS_ERROR_FACTORY_NOT_REGISTERED: Factory not registered
Source File: http://localhost/module/bajaScript/com/tridium/bajascript/bs.min.js
Line: 353

I traced the error in my JavaScript to when 'console.log' is called.

I then opened Scratch page (not JUST on this page but ANY web page) and get the following results...

console.log("hi");
/*
Exception: Factory not registered
@1
*/

Therefore it seems to be hitting on the same error.





Expected results:

console.log should just print information out to the JavaScript Console.
Severity: normal → major
>Running Firefox in safe mode works just fine.
What happens if you open about:config and change the value of
"javascript.options.methodjit.content" from "true" to "false" ?
By changing this setting, everything works again perfectly. I guess this is what Firefox Safe Mode is disabling.
>I guess this is what Firefox Safe Mode is disabling.
Correct, the safemode disables all add-ons, javascript jit, hardware acceleration, window settings and the social api.

Is there a public URL of your javascript web engine ?
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Hmm.  console.log works in general...

Matti, can you reproduce using the steps from comment 0?
no, I can't reproduce this with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0
I'll get my server online and post the URL and credentials to this issue. I'll have to do this next week when I'm back in the office.

Thank you for everyone's support so far. Once my web application is online it should be reproducible.
I've put a Server online for everyone. I've switched off all minified JavaScript code so you can see all the libraries and comments clearly. You'll see the errors in the error console. Once the page loads, I seem to get a multitude of errors (including the original one I mentioned sometimes). If I switch off the JIT (or use another browser like Chrome or IE), everything is fine.

http://80.176.168.128
username: mobile
password: niagara2756

If you could please let me know when it's ok for me to remove this Server (it's not something that I want to remain permanent).

Regardless, I think this should provide a good test case.
Hmm.  In a current nightly, Firefox 12, and Firefox 16 I don't see any issues loading that page.  But I'm on Mac, so this might be a 32-bit vs 64-bit issue...
Ah, in 32-bit mode I get a ton of errors, mostly about "too much recursion".
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
I will say that I've tested my JavaScript and don't have infinite recursion going on in my code. Of course, there is recursion (it's a heavy JavaScript Web Application Engine). However, it's nothing that a browser should have a problem with.
I tried some old nightlies in 32-bit mode.  2012-06-01 shows the problemm.  2012-04-01 seems to just hang.  2012-02-01 crashes on the page. 2011-12-20 (the Firefox 12 branchpoint) crashes...  Having a hard time finding when this worked in a Mac 32-bit build.  :(
Keywords: qawanted
Regression range:
Last good nightly: 2012-05-31
First bad nightly: 2012-06-01

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3aa566994890&tochan
ge=73783bf75c4c

I still see the issue in the current nightly Firefox build while it works in my Seamonkey 20121125003003 nightly with my usual addons.
Hmm. None of the JS checkins in that range are obvious smoking guns.  :(
Matti, what's the first inbound tinderbox-build that doesn't work?
We don't have earlier builds on the server. The oldest build is currently from 31.10.2012
BTW: I tried to reproduce this on Windows, but I'm not sure if the regression range from Comment 12 is actually "valid". I was able to reproduce that regression range with the official nightly builds. But when I tried to reproduce this with my own debug build with mozcommitbuilder/mozregression I already got the "too much recursion" error in a build with this changeset http://hg.mozilla.org/mozilla-central/rev/3aa566994890 (that's the cset from the 2012-05-31 nightly).
Debug builds can trigger out-of-stack earlier because the stack frames might be bigger...
Waiting for a sign that this is a widespread issue affecting our users before tracking.  If this is just debug and/or 64 bit Windows, I can't see how we'd block a release for it.
Lukas Blakk: This is a bug happening in regular windows 32bit Release builds.
David - can you get someone assigned to work on this so we can try to fix this regression before 18 ships?
Assignee: general → dvander
tracking-firefox18: ? → +
tracking-firefox19: ? → +
tracking-firefox20: ? → +
I wasn't able to reproduce this issue on Firefox 17.0.1, using the steps from the description and the credentials from comment 7, on a Windows 7 64-bit machine.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

This issue isn't reproducible on the latest beta, Firefox 18 beta 3, on the same machine.
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20121205060959

This issue isn't reproducible on the latest Nightly, on the same machine.
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:20.0) Gecko/20121206 Firefox/20.0
Build ID: 20121206030737

This issue isn't reproducible on the latest Aurora, on the same machine.
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20121206 Firefox/19.0
Build ID: 20121206042015

This issue isn't reproducible on the latest Firefox 10 ESR, on the same machine.
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.11) Gecko/20100101 Firefox/10.0.11
Build ID: 20121115102332

This issue isn't reproducible on the latest Firefox 17 ESR, on the same machine.
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121129050502
QA Contact: manuela.muntean
I disagree. I can still reproduce all of the bugs with Firefox 17.0.1 and the nightly build.

I still get too much recursion errors and a whole bunch of other ones in the console output.

Just go here and try it out...

http://80.176.168.128
username: mobile
password: niagara2756
Gareth, that is exactly what I've tested:

http://80.176.168.128
username: mobile
password: niagara2756

I've tested on all the builds mentioned in comment 22, but I couldn't reproduce the issue on neither one of them.
Please ensure you're not running Firefox in Safe Mode.
Please ensure you haven't got this setting set to false...

javascript.options.methodjit.content=true

As Boris (comment 9) has also suggested, please try the 32-bit build.
Gareth, I don't run Firefox in Safe Mode and I have this setting set to true: javascript.options.methodjit.content=true

All the builds tested were the 32-bit builds, except for the Nightly build.

Therefore, I've retested on the latest Nightly, with a 32-bit build. On this build I was indeed able to reproduce the issue.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121210 Firefox/20.0
Build ID: 20121210030747
Keywords: reproducible
Upon further review, this will not impact many users at all (and hasn't in the FF17 timeframe). Any impacted users could use a Nightly, once resolved.
tracking-firefox18: + → -
tracking-firefox19: + → -
tracking-firefox20: + → -
Assignee: dvander → general
Any progress on getting this issue patched? My JavaScript application engine won't work with out it.
I've just tested with Nightly 21.0a1. The problem still persists...

[10:23:21.581] NS_ERROR_FACTORY_NOT_REGISTERED: Factory not registered @ http://10.10.20.26/module/bajaScript/com/tridium/bajascript/browser.js:382

The Server that reproduces this problem is still online.

The problem doesn't show up in other browsers (Chrome, iExplore or Safari).
(In reply to Gareth Johnson from comment #29)
> I've just tested with Nightly 21.0a1. The problem still persists...
> 
> [10:23:21.581] NS_ERROR_FACTORY_NOT_REGISTERED: Factory not registered @
> http://10.10.20.26/module/bajaScript/com/tridium/bajascript/browser.js:382
> 
> The Server that reproduces this problem is still online.
> 
> The problem doesn't show up in other browsers (Chrome, iExplore or Safari).

I was able to reproduce the issue too, on the Nightly from the 25th of January 2013.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130125 Firefox/21.0
Build ID: 20130125031018

After connecting to the server, the page keeps on loading, without actually doing it. All I get is the "Loading" message, without any actual content.

After running 'console.log("hi");' in the Scratchpad, I get this error in the Error Console: 

Timestamp: 1/28/2013 12:12:48 PM
Error: NS_ERROR_FACTORY_NOT_REGISTERED: Factory not registered
Source File: http://80.176.168.128/module/bajaScript/com/tridium/bajascript/browser.js
Line: 382


On the other hand, on the latest Nightly, this issue is not reproducible anymore. (the Error Console doesn't show that error)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130127 Firefox/21.0
Build ID: 20130127031042

Gareth, can you still reproduce on the latest Nightly build?
I also don't get the error message with Firefox 18.0.1.
Yes unfortunately I still get lots of errors...

http://10.10.20.26/ord?station:|slot:/Building/Mobile/Lighting
user: mobile, password: niagara2756

Nightly - 32 bit on Windows 7 64 bit - 21.0a1

With JIT enabled (javascript.options.methodjit.content=true)...
[11:04:44.961] InternalError: too much recursion

With JIT disabled (javascript.options.methodjit.content=false)...
[11:07:54.211] TypeError: event is undefined

All ok on all other major browsers (IE, Chrome, Safari).

Here's part of the HTTP request header if it helps identifier more version specific information...

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130127 Firefox/21.0
(In reply to Gareth Johnson from comment #32)
> Yes unfortunately I still get lots of errors...
> 
> http://10.10.20.26/ord?station:|slot:/Building/Mobile/Lighting
> user: mobile, password: niagara2756
> 
> Nightly - 32 bit on Windows 7 64 bit - 21.0a1
> 
> With JIT enabled (javascript.options.methodjit.content=true)...
> [11:04:44.961] InternalError: too much recursion
> 
> With JIT disabled (javascript.options.methodjit.content=false)...
> [11:07:54.211] TypeError: event is undefined
> 
> All ok on all other major browsers (IE, Chrome, Safari).
> 
> Here's part of the HTTP request header if it helps identifier more version
> specific information...
> 
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130127 Firefox/21.0

Here are the results I get:

1) with the latest Nightly (User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130127 Firefox/21.0, Build ID: 20130127031042) and with JIT enabled (javascript.options.methodjit.content=true), I don't get any error messages

2) with the latest Nightly (User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130127 Firefox/21.0, Build ID: 20130127031042) and with JIT disabled (javascript.options.methodjit.content=false), I get these errors:

Timestamp: 1/28/2013 2:21:11 PM
Error: TypeError: event is undefined
Source File: http://80.176.168.128/module/mobile/com/tridium/mobile/util/rc/js/src/util.mobile.pages.js
Line: 249


Timestamp: 1/28/2013 2:21:37 PM
Error: TypeError: event is undefined
Source File: http://80.176.168.128/module/mobile/com/tridium/mobile/util/rc/js/src/util.mobile.pages.js
Line: 249


I can't connect to http://10.10.20.26/ord?station:|slot:/Building/Mobile/Lighting. 

I can only connect to:  http://80.176.168.128
                        username: mobile
                        password: niagara2756
Sorry, I got the IP wrong. The public is 80.176.168.128.
Removing the "regressionwindow-wanted" keyword, based on comment 12.

I can't reproduce this issue with neither one of the latest Nightly builds (32bit and 64bit), build ID: 20130721030203

When running "console.log("hi");" in Scratchpad, I get the expected "hi" typed in the Browser Console (former Error Console).

I also tried to connect to:  http://80.176.168.128, but without success.

Gareth, do you still experience this problem?
Flags: needinfo?(gjohnson)
Keywords: regressionwindow-wanted
Also removing the "qawanted" keyword. If the help of QA will be needed, please add the keyword back.
Keywords: qawanted
We've refactored our code so it's not recursive anymore. I've also had to remove the server. Currently this is no longer an issue to use.

I advise creating a test case that has a lot of recursion that will work as a good test platform.
Flags: needinfo?(gjohnson)
Assignee: general → nobody

I couldn't manage to reproduce this issue. Since the bug was logged 9 years ago, most likely isn't reproducible anymore for the reporter also.
Closing this bug as resolved: Worksforme

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.