Gecko 1.9 parsing XHTML files as HTML

RESOLVED INVALID

Status

()

Core
HTML: Parser
RESOLVED INVALID
11 years ago
11 years ago

People

(Reporter: Wayne DeAngelo, Assigned: Biesinger)

Tracking

({access, regression})

Trunk
x86
Windows XP
access, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 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: 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.

Comment 1

11 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

11 years ago
Smaller test case where file is getting parsed as html instead of XHTML: http://www.mozilla.org/access/dhtml/maincontent

Updated

11 years ago
Duplicate of this bug: 363588

Comment 4

11 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

Updated

11 years ago
Blocks: 342901

Comment 5

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

Comment 7

11 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?

Updated

11 years ago
Duplicate of this bug: 364234

Updated

11 years ago
Flags: blocking1.9?

Updated

11 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).
Depends on: 361892

Comment 10

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

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID

Updated

11 years ago
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.