Ticket #1704 (closed defect: fixed)

Opened 2 years ago

Last modified 9 months ago

FF3: Follow up with Mozilla about trac 1640

Reported by: jburke Owned by: jburke
Priority: normal Milestone: 1.1
Component: PackageSystem Version: 0.3
Severity: normal Keywords:
Cc:

Description

We have a workaround for the Firefox hang in trac #1640, but we should investigate more and engage Mozilla to find the core issue.

Change History

Changed 2 years ago by ttudor@…

A possible (and partial) workaround for #1640 is to :

1. Remove all src on images BEFORE bootstraping dojo.js
2. load dojo.js
3. Put original src back on images.

Details :


var gImgDeposit = [];

function evictImages() {

	var imgs = document.getElementsByTagName("img");
	var evicted = 0;
	for (var k = 0; k < imgs.length; k++) {
		var img = imgs.item(k);
		// This is for cached images
		if (img.complete) continue;
		
		gImgDeposit[evicted++] = {
			img : img,
			src : img.getAttribute("src")
		};
		img.setAttribute("src", "");			
	}			
}
	
function resurrectImages() {
	for (var k = 0; k < gImgDeposit.length; k++) {
		var img = gImgDeposit[k].img;
		var src = gImgDeposit[k].src;
		
		delete gImgDeposit[k];	
		img.setAttribute("src", src);
	}
	delete gImgDeposit;
}		

// DO THIS BEFORE INCLUDING dojo.js

var listener = function() {
	evictImages();
	document.removeEventListener("DOMContentLoaded", listener, null);
}
document.addEventListener("DOMContentLoaded", listener, null);

// ... LOAD DOJO 

// DO THIS AFTER HAVING LOADED dojo.js

listener = function() {
	resurrectImages();
	document.removeEventListener("DOMContentLoaded", listener, null);
}
document.addEventListener("DOMContentLoaded", listener, null);

Tried it with the current dojo HEAD and it works all right. dojo will still hang if you have really large (>64k) images included from css.

Sorry if this is not the right track to post the workaround.

Changed 2 years ago by bill

  • owner changed from alex to peller

Adam or Koranteng will handle this.

Changed 2 years ago by peller

Filed bug with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=358387 Will follow up with Mozilla team

Changed 2 years ago by peller

Ok, so we have our initial answer from Mozilla. The code is completely broken and is fixed in the trunk. I verified this. What does this mean? We won't see the fix in a release until mid-2007 at best (Firefox 3.0) Can we deal with the workaround until then?

The ThreadManager? is not something they will retrofit into 2.0. Apparently, it's too complex and probably too risky.

I'm thinking this will end up as a "won't fix" on our end, with us settling on one of our workarounds until FF3.0.

Changed 2 years ago by peller

  • status changed from new to closed
  • resolution set to wontfix

looks like we wait for this one

Changed 18 months ago by anonymous

  • milestone deleted

Milestone 0.4.1 deleted

Changed 11 months ago by jburke

  • status changed from closed to reopened
  • resolution deleted
  • milestone set to 1.1

Changed 11 months ago by jburke

  • owner changed from peller to jburke
  • status changed from reopened to new
  • summary changed from Follow up with Mozilla about trac 1640 to Firefox 3: Follow up with Mozilla about trac 1640

This may be fixed in Firefox 3. In that case, revisit the logic for enableMozDomContentLoaded.

Changed 11 months ago by bill

  • summary changed from Firefox 3: Follow up with Mozilla about trac 1640 to FF3: Follow up with Mozilla about trac 1640

Changed 9 months ago by jburke

  • status changed from new to closed
  • resolution set to fixed

(In [12432]) Fixes #1704: using DOMContentLoaded now for Firefox 3, since the hang bug is now fixed (as tested in FF 3beta3).

Changed 9 months ago by jburke

I also added a note to the bugzilla bug mentioning that the issue seems to be fixed.

Note: See TracTickets for help on using tickets.