Gecko 1.9 parsing XHTML files as HTML




12 years ago
12 years ago


(Reporter: deangelo, Assigned: Biesinger)


({access, regression})

Windows XP
access, regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





12 years ago
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:
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.

Comment 1

12 years ago
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

Comment 2

12 years ago
Smaller test case where file is getting parsed as html instead of XHTML:


12 years ago
Duplicate of this bug: 363588

Comment 4

12 years ago
Is this related to bug 361892?
Summary: Gecko 1.9 parsing XHTML file as HTML → Gecko 1.9 parsing XHTML files as HTML


12 years ago
Blocks: 342901

Comment 5

12 years ago
This was caused by bug 309438.
Doesn't that mean that this is a server-side configuration issue?
Blocks: 309438

Comment 7

12 years ago
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?


12 years ago
Duplicate of this bug: 364234
Flags: blocking1.9?


12 years ago
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).

Comment 10

12 years ago
Thanks this works:
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q\s*=\s*0(\.0{1,3})?\s*(,|$)


12 years ago
Last Resolved: 12 years ago
Resolution: --- → INVALID
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.