Closed Bug 364352 Opened 18 years ago Closed 18 years ago

Gecko 1.9 parsing XHTML files as HTML

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: deangelo, Assigned: Biesinger)

References

(
URL
)

Details

(Keywords: access, regression) 

Env: Firefox 3 (nightly build 20061218)

Problem: You cannot navigate the tree view using the arrow keys including left/right to collapse/expand. The twistie are not drawn correctly, they show up as " ". Double clicking with the mouse should toggle expansion, this also does not work.

Steps to recreate:
1. Start WindowEyes and Firefox, load url: http://www.mozilla.org/access/dhtml/tree
2. Try navigating with arrow keys, or left right arrow to collapse/expand, you will notice that you cannot perform these tasks.

NOTE: This is a regression since it works fine with Firefox 2.
Firefox 2 thinks the file is application/xml+xhtml, which is correct -- that's how Apache is serving it.
Firefox 3 thinks it is text/html -- why is that?
Assignee: aaronleventhal → mrbkap
Component: Disability Access APIs → HTML: Parser
QA Contact: accessibility-apis → parser
Summary: Can not Navigate through DHTML tree view. → Gecko 1.9 parsing XHTML file as HTML
Version: 1.8 Branch → Trunk
Smaller test case where file is getting parsed as html instead of XHTML: http://www.mozilla.org/access/dhtml/maincontent
Is this related to bug 361892?
Summary: Gecko 1.9 parsing XHTML file as HTML → Gecko 1.9 parsing XHTML files as HTML
Blocks: keya11y
This was caused by bug 309438.
Doesn't that mean that this is a server-side configuration issue?
Blocks: 309438
Maybe, but why we make everyone fix their servers when they've been following published docs on how to configure. It used to work and now it doesn't.

Everyone who's done this will have a painful discovery process when it breaks in FF3. What's the payoff for the change we've made?
Flags: blocking1.9?
Assignee: mrbkap → cbiesinger
The payoff is that our XHTML support is a LOT worse than our HTML support (e.g. no incremental rendering in XHTML).  If the site thinks that its XHTML and HTML are equivalently good, we should be using the HTML version.

What published docs is comment 7 referring to?  I suspect the docs were rather erroneous to start with... (e.g. suggested that the server configure XHTML and HTML with identical priority when you actually prefer the XHTML).
Depends on: 361892
Thanks this works:
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q\s*=\s*0(\.0{1,3})?\s*(,|$)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.