Last Comment Bug 828326 - Firefox 18 breaks my Javascript-heavy website when no other version of FF did.
: Firefox 18 breaks my Javascript-heavy website when no other version of FF did.
Status: RESOLVED INCOMPLETE
: regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 18 Branch
: x86 Mac OS X
: -- normal with 3 votes (vote)
: ---
Assigned To: general
:
Mentors:
Depends on:
Blocks: 789036
  Show dependency treegraph
 
Reported: 2013-01-09 06:54 PST by Matt
Modified: 2013-02-05 13:07 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Reporter's testcase as zip file (101.60 KB, application/zip)
2013-01-09 11:31 PST, Loic
no flags Details

Description Matt 2013-01-09 06:54:28 PST
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.101 Safari/537.11

Steps to reproduce:

In Firefox 15-17 my Javascript-heavy website worked flawlessly along with all other browsers (regardless of platform). The JS has zero lint errors. I utilize Underscore (1.4.3), Backbone (0.9.9), jQuery (1.8.3), GreenSock (animation library) and Isotope. I get no errors, only strange and inconsistent behavior with Firefox 18. In 17 everything worked as it should. For reference this site even works well in WinXP+IE8. 


Actual results:

See my support post: https://support.mozilla.org/en-US/questions/946291#answer-395321

In 18, sometimes everything works perfectly, then when you refresh the page, nothing will work, upon refresh it will work, but the results are very inconsistent at best. I have tried commenting out large chunks of the site and still see the odd behavior. It is the same in 18 regardless of platform. I have seen it happen on Windows XP, Windows 7 and OSX which leads me to believe it is something in Iron Monkey or the browser itself.


Expected results:

It should work consistently.
Comment 1 Loic 2013-01-09 06:58:36 PST
Please, post the URL of your website, or better, a minimal testcase (html file), so we could debug.
Comment 2 Matt 2013-01-09 07:37:32 PST
The site is not on the production server at the moment (staging only, not publicly accessible). For the minimal test case, I presume I would need to include all js as well? Would a jsbin or something similar work?
Comment 3 David Rajchenbach-Teller [:Yoric] (please use "needinfo") 2013-01-09 07:40:33 PST
Matt: personally, in these cases, I open a github page. This makes it easy to look at both the source code and the result "live". It would be great if you could do so. Otherwise, a jsbin will be quite fine, too.
Comment 5 Matt 2013-01-09 08:14:28 PST
I did not include the JSON file that populates the data on the site. Should I include a test JSON file?
Comment 6 Matthias Versen [:Matti] 2013-01-09 11:19:56 PST
What we bug triagers need is a simple testcase that can be accessed by us and of course steps to reproduce (what's exactly wrong). 
We can find the regression range with these information and move the bug to the right component so that a developer can fix it.

David: Please tell me how to run that testcase from github without a git client ?
A simple attached zip file would be much better IMO.
Comment 7 Loic 2013-01-09 11:31:09 PST
Created attachment 699967 [details]
Reporter's testcase as zip file
Comment 8 Alexander Ploner 2013-01-09 11:41:15 PST
The current testcase throws a javascript error in Firefox 18 but also in the current versions of Chrome and Opera (Win7).

Here is what firefox says:
TypeError: e is undefined @ http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js:2

It seems like it's the same error within the other browsers. I think the testcase doesn't work at all.
Comment 9 Matt 2013-01-09 15:01:38 PST
It may be some of the "anonymization" I did to the files as this project has not been publicly released yet. I was able to come up with a workaround by simply re-running functions to re-initialize the entire site, which seems to fix Firefox 18. The site should be launched either this coming Friday or the following Monday. After that I can release the code in-tact without the fixes I had to make.
Comment 10 Matt 2013-01-09 15:04:03 PST
From my testing though, it seems as if FF18 skips over large chunks of JS that gets cached whereas 15-17 never did (nor does any other browser).
Comment 11 ljohnson 2013-01-10 16:30:31 PST
@Alexander

Matt is seriously not the only person having this issue. I have an example site for you. Check out one of RocketThemes templates at (http://demo.rockettheme.com/may11/?presets=preset4).
Comment 12 Loic 2013-01-10 16:34:07 PST
@ljohnson: It looks like another issue with FF18, not related to this current bug. Could you file a new bug, please?
Comment 13 ljohnson 2013-01-10 16:40:07 PST
@Loic: I may be missing something but the title of this created report is called "Firefox 18 breaks my Javascript-heavy website when no other version of FF did." I couldn't describe the issue for my previous comment any better. If i'm in the wrong location can you point me to the solution.
Comment 14 Alexander Ploner 2013-01-10 16:56:57 PST
@ljohnson: With the sentence "I think the testcase doesn't work at all." I only wanted to say that something within the testcase is wrong, not that there is no issue.
Comment 15 Loic 2013-01-10 17:23:41 PST
(In reply to ljohnson from comment #13)
> @Loic: I may be missing something but the title of this created report is
> called "Firefox 18 breaks my Javascript-heavy website when no other version
> of FF did." I couldn't describe the issue for my previous comment any
> better. If i'm in the wrong location can you point me to the solution.

Because the cause is different. I filed the bug 829384 for you, you need to update the MooTools version on your side to fix it.
Comment 16 ljohnson 2013-01-10 17:24:29 PST
@Alexander Ploner

I actually found the fix to my problem. I had to add some additional code to a file in my site.

--------------------------------------------------

$doc->addScriptDeclaration("
String.prototype.contains = function(string, separator){
return (separator) ? (separator + this + separator).indexOf(separator + string + separator) > -1 : String(this).indexOf(string) > -1;
};");	

--------------------------------------------------

Reference1: https://groups.google.com/forum/?fromgroups=#!topic/mootools-users/W7MHwTFHYQ4

Reference2:http://www.rockettheme.com/forum/index.php?f=528&t=186020&p=917487&hilit=%20firefox%2018%20&rb_v=viewtopic#p917487

Hope this can be helpful. Peace out peoples.

By the way this additional code wasn't needed until after I updated to Firefox 18.
Comment 17 ljohnson 2013-01-10 17:26:03 PST
@All

Oh yeah, now you can see what my site was supposed to look like.

SevereTech.com
Comment 18 Loic 2013-01-11 06:34:45 PST
(In reply to Matt from comment #9)
> It may be some of the "anonymization" I did to the files as this project has
> not been publicly released yet. I was able to come up with a workaround by
> simply re-running functions to re-initialize the entire site, which seems to
> fix Firefox 18. The site should be launched either this coming Friday or the
> following Monday. After that I can release the code in-tact without the
> fixes I had to make.

Yes, I think your zipped testcase is broken somewhere because I got only a gray background with the word "loading" displayed during a fraction of sec (in all Firefox versions).

When your website is out, repost here so we could test in better conditions.
Comment 19 Matt 2013-01-11 06:36:17 PST
I am prepping a deployment package today to hand off to my client. Hopefully it will go live today or Monday so I can put the source on Github or my personal server with and without the fix. The thing that boggles my mind is no version of Chrome has an issue, worked on all prior versions of Firefox (regardless of OS), works on iPad, iPhone and all Android, works on IE7, IE8, IE9 and IE10 between XP and Win 7. My fix was simply re-call my initialization functions, as weird as that is (and bad practice...)
Comment 20 Matt 2013-01-11 06:48:22 PST
@Loic The 'loading' on the landing page is preloading a few images before it fades in the content. I don't think I included any of the imagery in that test case so my apologies for not having that working. As stated above I should have a working live copy available soon.
Comment 21 Ralf Vitasek 2013-01-19 01:34:47 PST
I've noticed this Bug too happening on an ExtJS 4.1 heavy site.
Appearing very randomly so i wasn't able to reproduce yet (on OSX 10.8.2).
Colleague of mine noticed the same glitchy* behavior the other day on Win7.

Not 100% sure but i didn't see the problem in the FF18 beta which i was using for a couple of weeks to get Retina support.

* Things like tool-buttons in panel headers were placed left ontop of title icons instead of right hand side. Or heights were completely garbled. Tab-Panels were completely malfunctioning. 1-3 reloads usually fixes the problem.
Comment 22 :Ms2ger (⌚ UTC+1/+2) 2013-01-19 02:54:54 PST
Another String#contains regression... Why have we not backed it out, exactly?
Comment 23 :Benjamin Peterson 2013-01-19 06:23:45 PST
Is there some specific site to track here?
Comment 24 Matt 2013-01-22 11:10:26 PST
Site that functions (with fix) is available at: http://www.jdrf.org/2012annualreport

I had to re-init a handful of functions in order for Firefox 18 to play nicely.

In main.js: 

jdrfApp.Init.Start = function() {
	jdrfApp.Utils.initIsotope();			// not being re-run
	jdrfApp.Utils.initIsotopeClicks();		// not being re-run
	jdrfApp.Views.hoverTheWall();			// not being re-run
	jdrfApp.Utils.hookupModals();				// not being re-run
};

Then I call the jdrfApp.Init.Start(); at the end of the main.js file. I am working on putting up an un-minified version on a personal dev server with the fix removed.
Comment 25 :Benjamin Peterson 2013-02-05 13:07:59 PST
I'm closing this, since there's nothing specific we can track on this bug.

Note You need to log in before you can comment on or make changes to this bug.