Closed Bug 787782 Opened 7 years ago Closed 3 years ago

Browser freezes and hangs with small jQuery code, which implements a slider.

Categories

(Core :: General, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
platform-rel --- ?

People

(Reporter: lapynow.d, Unassigned)

Details

(Whiteboard: [platform-rel-jQuery])

Attachments

(3 files)

Attached file site_bug.html
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20120828083259

Steps to reproduce:

There is a simple page with elastic layout and some jQuery that implements sliding content of main part of the page. Troubles appear when i click on a menu items "Slide -1, Slide -2,..., home"


Actual results:

When I do some serial clicks on different menu items(Slide -1, Slide-2, etc), on a 3-5th click slide animation freezes and browser sometimes hangs for a short (<15s) time. Result: i cant smoothly switch slides.

Important notes:

1. 
When i test page with any opened console (firebugs,debug or a something from a web-development tools(shift-F2)) - any freezes or hangs are disappear and all works fine.

2. 
Page works fine in all major browsers, include FF13.

3.
Page works fine with jQuery 1.7.2, but with latest (1.8) I have troubles.

4.
Page is loaded to http://jsfiddle.net/KKmTD/4/ and there is no problem with displaying.


Expected results:

When buttons "Slide-1,..., Slide-4, home" are clicked, div.shell shall moving to the left(regarding to css "left" properity) for a 100%, 200%, ..., 400% and 0% respectively. In all other this is a common css properity animation.
Attachment #657658 - Attachment mime type: text/plain → text/html
MFM with jQuery latest(1.8.1) in Firefox16.0beta, Aurora17.0a2 and Nightly18.0a1 as well.
(In reply to Alice0775 White from comment #1)
> MFM with jQuery latest(1.8.1) in Firefox16.0beta, Aurora17.0a2 and
> Nightly18.0a1 as well.
Sorry, whats mean "MFM"?
"Works for me", it works as expected.
> "Works for me", it works as expected.
Thanks for explanation.

So, I have tried check described problem in clear Firefox 15 and have cathed the same problem.
Again its cures with opened console for me.
I'm able to reproduce the hang of the browser after 4-5 clicks on the menu items. Disabling HWA doesn't change anything. I didn't find any regression.
OK I can reproduce.

1. Start New Profile
2. Open attached site_bug.html
3. Reduce contents height approx 350px
4. Enlarge contents width approx 1200px
5. Try to reproduce(Click menus)
6. Change browser height 
7. Repeat step 3
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
Product: Firefox → Core
Version: 16 Branch → Trunk
Attached file stack
It looks like an endless number of calls to "elem.style.right" coming
from within jQuery.  I'm not very good at debugging script code though.
So is this a regression?  I don't know how to reconcile comment 5 with note 2 from comment 0.
I don't think it's a regression, I tried with various old versions (with mozreg) and all have the same behavior: when the Firefox window is maximized, it hangs. If I reduce the size of the window (by half e.g.), sliding is smooth and there is no browser hang.
OK, so I do see the lots of elem.style.right sets coming from jQuery.

The interesting thing are the values.  Here are a few, in order:

  "299.9998871029541%"
  "300.00108578874296%"
  "299.9998871077436%"
  "300.0010857935324%"
  "299.99988711253303%"
  "300.00108579832187%"

etc.  Looking at the jQuery source at http://code.jquery.com/jquery-1.8.1.js the relevant bit is on lines 8426 to 8439.  We enter that loop with, in my case, target == 5005.5.  If I add dump() calls before the loop condition check to see what the values of the variables are, I see:

  tween.cur(): 5005.48
  target: 5005.5
  Scale: 0.9999960043951652
  prevScale: 1.0000039956048348
  tween.cur(): 5005.52
  target: 5005.5
  Scale: 1.0000039956048348
  prevScale: 0.9999960043951652

repeating over and over and over.  So clearly we have "scale !== 1 && scale !== prevScale", but that's not saying much.

Looking on the layout side, we do in fact have frames whose right is at 5005.5px (or more precisely 300330 app units), as far as I can tell.  But the corresponding specified style is not exactly 300%; it's just a value close enough to get the right layout.

This seems like a classic mistake in programming with doubles to me, and a jQuery bug.  The only bug I see on our side is us not putting up a slow script dialog fast enough.

Mats, want to file on jQuery, or should I?
Whiteboard: [platform-rel-jQuery]
platform-rel: --- → ?
https://bugs.jquery.com/ticket/12447 (the bug that 12495 was duped against) has been fixed, so let's close this.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.