base element target attribute for sibling frame no longer works in Hyperlatex output

RESOLVED FIXED in mozilla2.0b10

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: Carey Evans, Unassigned)

Tracking

({html5, regression})

unspecified
mozilla2.0b10
html5, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

7 years ago
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?
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: html5, regression
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).
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Component: HTML: Parser → English US
OS: Windows 7 → All
Product: Core → Tech Evangelism
QA Contact: parser → english-us
Hardware: x86 → All
http://sourceforge.net/mailarchive/forum.php?thread_name=03C4E1AD-C123-4829-BCFB-A5DE115FD970%40iki.fi&forum_name=hyperlatex-users
I posted to the HTML WG, too:
http://lists.w3.org/Archives/Public/public-html/2010Sep/0062.html
Depends on: 619220
Component: English US → General
Product: Tech Evangelism → Firefox
QA Contact: english-us → general
blocking2.0: ? → ---
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
Bug 619220 fixed this in a non-evang way.
Assignee: hsivonen → nobody
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Component: English US → DOM: Core & HTML
Product: Tech Evangelism → Core
QA Contact: english-us → general
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
You need to log in before you can comment on or make changes to this bug.