Firefox gets stuck in endless(?) loop of XUL_GetFileFromPath on AJAX-heavy page

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
10 years ago
8 years ago

People

(Reporter: jens-bugzilla.mozilla.org, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CLOSEME 2010-11-01])

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9) Gecko/2008061004 Firefox/3.0

Hello,
the above URL (pw protected but I can provide a copy) contains a web project with lots of JS and AJAX elements that are drag&drop enabled like this:

<span id="zuser_1977" class="zuser country_5" title="[PAR] McDonald, Sarah; 0; Kanada">1977<span class="zuser_age">0j</span>
</span>
<script type="text/javascript">
//<![CDATA[
new Draggable("zuser_1977", {revert:false})
//]]>
</script>

This is code using the Scriptaculous/Prototype JS Framework.

Problem: Firefox loads the page and after finishing loading, suddenly spikes CPU usage up to 100% and freezes (OS X shows the spinning beachball).

The more of the above fragments I use, the longer the freeze time. With several hundred fragments I had to wait for ten minutes.

I will attach the HTML code in question, and a backtrace, shortly.

Safari 3.1 on the same machine, using WebKit, also spikes CPU load after loading but only for a split second, even if there are thousand such fragments on the page.

This might be related to Bug #434513 which also reports XUL_GetFileFromPath high load because the function was (ab)used by a plugin (AFAIunderstand). But it's not the same problem.


Reproducible: Always
(Reporter)

Comment 1

10 years ago
Created attachment 324924 [details]
backtrace created by OS X for Firefox after killing it, stuck in XUL_GetFileFromPath
(Reporter)

Comment 2

10 years ago
Can anybody comment on this bug? I tried the same site using Safari and FF2, and both don't have this problem and display the page at once.

Thanks!
(Reporter)

Comment 3

10 years ago
Update & Workaround:

* The freeze (long delay) happens within Prototype's "getstyle" function (Prototype JS 1.5.1).
* It is apparently caused by Prototype adding "style=position: relative;" to each Draggable <span> object.
* If I add "position: relative" to the span's CSS in my main CSS file, the time spent in GetStyle() is much, much smaller (e.g. 500ms instead of 23 seconds).

So *something* in Prototype's "GetStyle" function, quoted below, is causing this bug.


prototype.js implementation:

Element.Methods = {

  // ....

  getStyle: function(element, style) {
    element = $(element);
    if (['float','cssFloat'].include(style))
      style = (typeof element.style.styleFloat != 'undefined' ? 'styleFloat' : 'cssFloat');
    style = style.camelize();
    var value = element.style[style];
    if (!value) {
      if (document.defaultView && document.defaultView.getComputedStyle) {
        var css = document.defaultView.getComputedStyle(element, null);
        value = css ? css[style] : null;
      } else if (element.currentStyle) {
        value = element.currentStyle[style];
      }
    }

    if((value == 'auto') && ['width','height'].include(style) && (element.getStyle('display') != 'none'))
      value = element['offset'+style.capitalize()] + 'px';

    if (window.opera && ['left', 'top', 'right', 'bottom'].include(style))
      if (Element.getStyle(element, 'position') == 'static') value = 'auto';
    if(style == 'opacity') {
      if(value) return parseFloat(value);
      if(value = (element.getStyle('filter') || '').match(/alpha\(opacity=(.*)\)/))
        if(value[1]) return parseFloat(value[1]) / 100;
      return 1.0;
    }
    return value == 'auto' ? null : value;
  },

  // ...
}
This is a mass search for bugs that are in the Firefox General component, are
UNCO, and have not been changed for 800 days and have an unspecified version. 

Reporter, can you please update to Firefox 3.6.10, create a fresh profile,
http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you
still see the bug, please update this bug. If the issue is gone, please set the
resolution to RESOLVED > WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.