This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9650 - WHATWG Spec Web Site Freeze
Summary: WHATWG Spec Web Site Freeze
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-03 22:48 UTC by Garrett
Modified: 2010-10-04 14:32 UTC (History)
6 users (show)

See Also:


Attachments

Description Garrett 2010-05-03 22:48:50 UTC
The website of the editors draft is freezing Firefox. The freeze lasts for about 120 seconds (2 min). 

After being frozen, the various status notifications that are added to the page. 

When the page is loaded with javascript disabled, Firefox does not freeze.

http://www.whatwg.org/specs/web-apps/current-work/#the-input-element-as-domain-specific-widgets

The problem should be fixed so that users are not subjugated to having the browser taken over by javascript. 

Although unrelated, the page also frequently will display javascript errors, such as:

| fixBrokenLink is not defined
| [Break on this error] fixBrokenLink();
| Overview.html (line 281)

I suggest instead "fixBrokenSite".
Comment 2 Lachlan Hunt 2010-05-06 15:48:25 UTC
The problem here is this script.

http://www.whatwg.org/specs/web-apps/current-work/status.js

Use an ad blocker to manually block that script and you'll have no problem.  Alternatively, if you have time, volunteer to rewrite that script so that it's not so inefficient.
Comment 3 Garrett 2010-06-24 21:51:56 UTC
Performing DOM traversal on page load is inherently inefficient. 

The larger the document, the more of a problem it will be. The problem only gets worse on slower machines and so testing it on a fast machine is not going to reveal much. 

Instead of trying to fix it; don't do DOM traversal onload at all. 

I see the resolution WORKSFORME. Does that mean the problem is solved by using a script blocker, as indicated in comment #2, or does it mean that the problem wasn't observable? When changing status, please provide a short comment for others to read - thanks.