Closed Bug 209637 Opened 20 years ago Closed 7 years ago

Will not open XHTML mp with MIME application/vnd.wap.xhtml+xml

Categories

(Core :: XML, enhancement)

Product:
Core
Component:
XML
Platform:
x86
Windows 2000
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla52
Tracking Flags:
Tracking Status
firefox51 --- fixed
firefox52 --- verified

People

(Reporter: janegil, Assigned: hjtoi-bugzilla)

References

(Depends on 1 open bug,
URL
)

Details

Attachments

(2 files)

patch
3.26 KB, patch
bzbarsky
: review-
Details | Diff | Splinter Review
Complete patch
4.85 KB, patch
bzbarsky
: review+
gchang
: approval-mozilla-beta+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529

Mozilla doesn't "know" that it is able to read files with MIME type
application/vnd.wap.xhtml+xml. These pages are XHTML Mobile Profile, which is a
subset of strict XHTML, so Mozilla should not have any problem reading them. 

Reproducible: Always

Steps to Reproduce:
1.http://landsbank.fo/tools/
2.Follow link to XHTML Mobile Profile
3.

Actual Results:  
Mozille asked what to do with files of type application/vnd.wap.xhtml+xml.

Expected Results:  
It should have shown the page, just like it does with
http://landsbank.fo/tools/xhtml.xml.cfm

application/vnd.wap.xhtml+xml is a better MIME for these pages than text/html,
as it tells the telephones that this is really XHTML mp, not just any old HTML.
see bug 155730 for details on support for documents with +xml mime types.
Depends on: */*+xml
Using generic XML view for unknown '+xml' types would be an improvement.

But 'application/vnd.wap.xhtml+xml' is actually HTML, and should be displayed 
as such.
Yes. By fixing bug 155730.
Yes. It looks like Mozilla (and Opera, see http://landsbank.fo/test/xhtml.xml) 
will display text/xml as HTML when possible, so fixing 155730 will be enough.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/


*** This bug has been marked as a duplicate of 155730 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
This isn't a dup.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
QA Contact: ashshbhatt → xml
Attached patch patch — — Splinter Review 
I'm seeing this on http://m.tvgids.nl .
On Fennec, I'm getting automatically redirected to that page, when trying to visit http://www.tvgids.nl .

I tried this patch, but it loads an about:blank page on m.tvgids.nl. I guess I need to change more stuff or something? Or maybe this needs a clean rebuild?
Attachment #549763 - Flags: review?(bzbarsky)
Comment on attachment 549763 [details] [diff] [review]
patch

Changing anything in parser/htmlparser/ is unlikely to help you. In any case, I'm not convinced we should support this.
Attachment #549763 - Attachment is patch: true
Attachment #549763 - Attachment mime type: text/x-patch → text/plain
You need to change gXMLTypes in nsContentDLF.cpp as well.

Changing parser/htmlparser is in fact correct here for now; just ignore Ms2ger on that point.  ;)

But I am also not entirely convinced we should support this.
How common is this mimetype? Do we have any data? Is it a registered mimetype?

I think I'd prefer generic support for application/*+xml instead.
This particular mime type is the "standard" (not registered, of course, though some other application/vnd.wap* types are) WAP MIME type.  So it's somewhat common for mobile-specific sites.
I guess I'm not up on the latest specs here since WAP used to be something wholly different from XHTML.

I'm still curious to know if we have any data backing up that this is a "common" mimetype.
Fennec seems to encounter this from time to time. The latest occurence of this is bug 678489.
Comment on attachment 549763 [details] [diff] [review]
patch

r- per comment 10.  If we do want this, the code still needs fixing.
Attachment #549763 - Flags: review?(bzbarsky) → review-
We're getting a request for this from a partner in order to pass compliance tests. In particular, the first test on this page:

http://spe.mobilephone.net/wit/xhtmlv2/struc.xhtml
(In reply to Boris Zbarsky [:bz] from comment #10)
> You need to change gXMLTypes in nsContentDLF.cpp as well.

Shouldn't it go into gHTMLTypes so it's treated the same as XHTML?

I've unbitrotted this patch, but going to:

http://spe.mobilephone.net/wit/xhtmlv2/struchtml1.xhtmlmp

tries to download the file instead of displaying it. Has something changed?
Attached patch Complete patch — — Splinter Review 
This is an update to the previous patch with two additions.

1. addition of APPLICATION_WAPXHTML_XML to gHTMLTypes in nsContentDLF.cpp
2. change to nxHTMLDocument.cpp to recognize APPLICATION_WAPXHTML_XML as xhtml.

With these two changes, the test is loading.
Attachment #8760456 - Flags: review?(jonas)
> Shouldn't it go into gHTMLTypes so it's treated the same as XHTML?

That depends.  Do you want it to create an HTMLDocument or not?  If you _do_, it needs to go into gHTMLTypes and you need to make changes to at least nsHTMLDocument::StartDocumentLoad to set "xhtml" to true in this case and whatnot.  As you noticed.  Possibly other things too; I'm not sure offhand.
> Possibly other things too; I'm not sure offhand.

It seems to work pretty well.

FYI, I put you (bz) as the reviewer, but you aren't taking review request :). No idea if Jonas has bandwidth.
> Do you want it to create an HTMLDocument or not?  If you
> _do_, it needs to go into gHTMLTypes and you need to make changes to at
> least nsHTMLDocument::StartDocumentLoad to set "xhtml" to true in this case
> and whatnot.  As you noticed.  Possibly other things too; I'm not sure
> offhand.

I'm pretty sure that we'd want to do this. If something is worth parsing as (X)HTML, then it's worth giving a HTMLDocument.
Comment on attachment 8760456 [details] [diff] [review]
Complete patch

Review of attachment 8760456 [details] [diff] [review]:
-----------------------------------------------------------------

I suspect someone other than me should review this. I don't really know these tables at all.
Attachment #8760456 - Flags: review?(jonas) → review-
The attached patch _does_ create an HTMLDocument, fwiw.
Comment on attachment 8760456 [details] [diff] [review]
Complete patch

Review of attachment 8760456 [details] [diff] [review]:
-----------------------------------------------------------------

Ah, ok, I'll remove my r- then. But someone else which knows this code better should do the reviewing.
Attachment #8760456 - Flags: review-
Comment on attachment 8760456 [details] [diff] [review]
Complete patch

r=me
Attachment #8760456 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/10243fd520ca
Status: REOPENED → RESOLVED
Closed: 18 years ago → 7 years ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Comment on attachment 8760456 [details] [diff] [review]
Complete patch

Approval Request Comment
[Feature/Bug causing the regression]: No regression - adds support for new mime type.
[User impact if declined]: Unable to view some mobile XHTML files
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: No
[Is the change risky?]: No
[Why is the change risky/not risky?]: Very contained, only affects this mime type.
[String changes made/needed]:

I'm requesting uplift on this because we need to do some mobile OMA testing, and I'd like to be able to test against Firefox 51.
Attachment #8760456 - Flags: approval-mozilla-beta?
Hi Florin,
Can you have someone in your team to help verify if it's fixed on latest nightly? Thanks.
Flags: needinfo?(florin.mezei)
Comment on attachment 8760456 [details] [diff] [review]
Complete patch

Add support for new mime type. Beta51+. Should be in 51 beta 8.
Attachment #8760456 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
This issue is Verified Fixed for Nightly 53.0a1 (id: 20161214030231) and Aurora 52.0a2 (id: 20161215004017) on a Windows 10 x64 machine.

Please note that the link used for verifying this was 
http://spe.mobilephone.net/wit/xhtmlv2/struchtml1.xhtmlmp
status-firefox52: fixed → verified
Flags: needinfo?(florin.mezei)
You need to log in before you can comment on or make changes to this bug.