ELinks is not recognizing MIME type text/xml+xhtml nor text/xml, which are the recommended types for XHTML, on added file extensions. This means that, despite XHTML 1.0 and XHTML 1.1 documents are valid HTML 4 they are not recognized unless you use text/html type. I haven't been able to test through HTTP yet, though. Severity is assuming the bug happens also on network, so lower to important if it isn't the case. The solution depends on whether the problem is just a file handling issue or general, but it's trivial in both cases: - If it's a file handling issue (it works on HTTP) it's just a matter of finding out why only text/html is accepted in the case of files. I'm sure it is straightforward, and can volunteer for a patch in this case. - If it's general all necessary is accepting both types and assuming they are valid HTML. Parts of XHTML 2 might not display correctly yet, but this has ever happened with all newer versions of HTML on legacy browsers, and is not a problem until it gets supported. I have no doubt XHTML 1 is fully supported, though, and has ever been, except for this MIME type issue.
tag 1036445 -patch severity 1036445 important quit Could you test the version in experimental (0.16.1.1) /? No patch attaxhed, removing patch tag. Quoting https://www.debian.org/Bugs/Developer : " grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. " hence severity is either normal or important. Please attach a file that I can use to test the issue.
tag 1036445 -patch severity 1036445 important quit Could you test the version in experimental (0.16.1.1) /? No patch attaxhed, removing patch tag. Quoting https://www.debian.org/Bugs/Developer : " grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. " hence severity is either normal or important. Please attach a file that I can use to test the issue.
severity 1036444 important
severity 1036445 grave
thanks
No, I have no box available with experimental at this time, sorry.
But it makes little difference. The bug was filed for version
0.13.2-1+b1 so it's in all supported releases this version exists where
you have to test it, besides sid.
Please, also note experimental is not the right release for development
usually, that would be sid (unstable).
Patch tag does not mean necessarily that a patch is attached. A simple
description for fixing it is enough:
patch
A patch or some other easy procedure for fixing the bug is
included in the bug logs. [...]
In this case my procedure was at the bottom of my report. It should be
easy enough for the developers.
As in #1036382, all you have to do is confirm you can reproduce it with
the same package version, confirm the bug is not caused by a Debian
patch, and forward the report to upstream. Also try to reproduce
through network, if you can.
I wonder why you think severity is normal or important, and more so why
you don't even seem to know which of these is supposedly. Quoting the
severity's description doesn't provide your reason :)
My reasoning is analogue to the one I had for #1036382 initially, which
is provided there and in this report.
Considering you are maintaining a web browser you should be able to
make up an elementary XHTML 1.1 test file yourself. Anyway, as I said,
I provided one also to you in #1036382, named hello-world.xhtml. Just
rename to
hello-world.xhtml.en
Hi again أحمد المحمودي, It seems this night with sleep deprivation I became sloppy. This went to #1036444: Sorry that I mistook you for the maintainer of that bug. Conversely this went to #1036445: Ditto. My most sincere apologies for the confusion.
Control: tags -1 - patch This is clearly neither a patch nor a "some other easy procedure for fixing the bug".
tag 1036445 -patch severity 1036445 important quit According to DDs on #debian-mentors: 2023-05-22 02:05:31 pabs AnAnt: definitely not grave, important at the highest