[whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)

[Garrett Smith]

On 8/10/10, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 7 Jul 2010, Garrett Smith wrote:
>>
>> This is about the fourth time I've said it here. Can the person in
>> charge of writing the slow and buggy ajvascript on the HTML 5 spec
>> please remove that?
>>
>> The problem is that that whatwg page causes freezes and crashes [...]
>
> That sounds like a bug in the browser. No page should cause such problems.

The halting problem is caused by the program running in the
environment. While the environment is not something you get to control
(that's my browser), you see what the code is doing.

> I don't see such problems with the browsers I use to view the spec.
>

I'm running Firefox 3.6.4 on windows 7, on a 2ghz intel dual core with
2g ram. Nothing to brag about, but I've seen faster applications
running on IE5 on Windows 98.

>
> On Wed, 7 Jul 2010, Boris Zbarsky wrote:
>>
>> I'll just note that part of the reason it's a "stress test", apart from
>> the old Firefox issue, is that it tries to be clever and not hang the
>> browser.... which actually causes the browser to do a lot more work.
>> On my machine here, if the spec's script were not trying for the clever
>> thing, it would take about 1-2 seconds (with a completely hung browser
>> during that time) to do what it currently takes anywhere from 8 to 25
>> seconds to do, during which time the browser is largely unresponsive
>> anyway.
>

Even 1 second would be still too long.

> I've tried to tweak the scripts to not be quite as silly in the way they
> split up the work (in particular, now they won't split up the work if it's
> being done fast -- in browsers I tested, this reduced the problem just to
> the restyling being slow, in some cases taking a few seconds).
>

Well its still freezing my Firefox.

Looping through the dom on page load is something that is best avoided.

Most (if not all) of this stuff seems best suite for server-side
logic. I see navigational and state management features that could be
done on the server. For example:

// dfn.js
// makes <dfn> elements link back to all uses of the term

However the freezing seems to be coming from toc.js.

Navigation should be done in HTML, not in javascript. The code itself
has problems and shouldn't be expected to do anything more than throw
errors.

toc.js:
while (li) {
    if (li.nodeType == Node.ELEMENT_NODE) {
    var id = li.firstChild.hash.substr(1);

Don't expect nonstandard global `Node` property; there isn't any
standard that says it should be there and it won't work cross browser.
You could use your own constants, but what you really want here is
list's items, since no such property exists, you can use
list.getElementsByTagName("li").

Next, the code expects that li.firstChild is an object with a hash
property (string). That could be an <a>. What happens if whitespace or
a comment appears before that <a>? Unless the script is generating
that HTML, it would be safer to use li.getElementsByTagName("a"), or
at least to perform an existence inference check;

var hash = li.firstChild && typeof li.firstChild.hash == "string";
if(hash) {
  hash = hash.substring(1);
}

String.prototype.substr is nonstandard.

String.prototype.substring is specified standard by ECMA. That use of
substr there won't trigger the IE bugs, but why use a nonstandard
method when a normatively spec'd method is available and known to work
more consistently?

The javascript navigation won't work if the script fails or throw
errors. There is no reason to expect that Node is present and if it is
not present, the script will throw errors and that is the author's
fault.

Can I ask why you chose to use javascript to create navigation? Is it
because you ahve to deal with disparity between the server
environments on whatwg.org and w3.org? Cna you do it another way?

It is getting late now. I may try and take another look at toc.js
tomorrow. I'd much rather see a server side strategy used to manage
the navigation, though.

I would also like to quickly mention that the "Submit Review Comment"
as well as the "status" feature that jumps around on scrolling both
get in the way and are distracting. I'd like to see the status as a
static, non moving element on the page.

I'd like to see the "Submit Review Comment" feature not get in the way
of my browser's "find" feature. When the browser's "find" is used, the
text that is highlighted is hidden under that element. This forces the
user to return focus to the document, scroll down a bit past that
"Submit Review" element, read the highlighted text to see if the
context the text appears in is in the context of what he was looking
for, and if it isn't, then re-focus the "find" feature and repeat that
process. Instead, I'd prefer not to have that feature get in the way.

Garrett