User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4) Gecko/20100818 Firefox/4.0b4 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4) Gecko/20100818 Firefox/4.0b4 Hyperlatex output such as that at http://hyperlatex.sourceforge.net/html/hyperlatex.html and http://lampwww.epfl.ch/~odersky/whatsnew/collections-api/collections.html includes a <base target="main"> element in its navigation frame. In Firefox 3.6, Chrome 5, Safari 5, and IE6 (but not IE8 or IE9 preview 4), this opens all the links in the navigation frame in the sibling frame named "main". The HTML5 spec describes the target attribute on the base element at http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-base-element , and as far as I can tell it describes the old behaviour. Setting html5.enable to false restores the expected behaviour. Reproducible: Always Steps to Reproduce: 1. Ensure the html5.enable preference is set to true. 2. Load http://hyperlatex.sourceforge.net/html/hyperlatex.html . 3. Click a link in the left sidebar. Actual Results: The link destination is opened in the left hand frame named "contents". Expected Results: The link destination should be opened in the right hand frame named "main".
Henri, can you take a look please?
This bug is invalid per spec. The page puts <base> inside <body>. HTML5 only considers <base target> that appears in head: http://www.whatwg.org/specs/web-apps/current-work/#following-hyperlinks The old parser hoists <base> into head but the new parser (per spec) doesn't. Since the page also doesn't work in IE8/9, I'm not treating this as a Gecko or spec bug but as an evangelism issue (even though I realize it's a bug in a generator program that's used on multiple sites). Since the bug tracker on SourceForge had never been configured for use, I sent email to the hyperlatex-users mailing list that has had some activity this year even though the project otherwise seems dormant or dead (but e.g. Ubuntu has a hyperlatex package in the latest package repos).
I posted to the HTML WG, too: http://lists.w3.org/Archives/Public/public-html/2010Sep/0062.html
Bug 619220 fixed this in a non-evang way.