Comment 40 for bug 228988

On 2010-09-15 22:38, papukaija wrote :
> You were asked in comment 32 to reproduce this bug in the current
> development release of Ubuntu which is Maverick. I can't reproduce this
> bug in Lucid wit the given URL with UTF-8 encoding. That's why I asked
> you in comment 34 to give another URL to test with. Ideally that URL
> should produce valid HTML (the given URL's html has 26 errors and 6
> warnings). I'm a bit confused, you wrote "In particular, I explained
> that the character set should be described within the HTML file
> exclusively." while your given URL doesn't have any meta tags in its
> header
I'm sorry I don't run Maverick. Nor Lucid yet.
Please note that these problems are browser issue, not system issues.

I'm surprised you were not able to reproduce this problem.
I spent ½ h getting my hands on some Lucid, 2 min reproducing the bug as
I described it before and 1 more h making the same report for Lucid as I
did before. What I attached for today's test is the twin picture of the
former.

A character set issue is not affected by the number of errors in a
page. It's only affected by its number of character set related errors
(just like the number of bumps on your car cannot be the reason why you
hit another car).

If you look carefully at your W3 HTML validation for the two frames in
the attached picture, you will read as the first line (as if most
important) :
No Character Encoding Found! Falling back to |windows-1252|.
Having no character encoding statement is *NOT* an error. And as far as
I know, the fall-back character set is ISO8859-1, not |windows-1252|
which is a proprietary character set that the official standards are
avoiding, or trying to. But that doesn't change our discussion.

Now if you look carefully at the Firefox/View/Character Encoding, you
will see that what Firefox used as fall-back encoding is UTF-8.

Now, does that discrepancy between Firefox and the sacred HTML
validation (and what seems obvious to only me) prove enough what I've
been trying to explain during 2½ year to people relaying to say that
there is no bug, turning a very complete report to incomplete and making
it a mess. I did not appreciate to be accused of tweaking the browser in
order to exhibit bugs that don't exist.

NB: For exactly the same experiment, Internet Explorer (which is a Web
explorer actually, traceroute is an Internet explorer) correctly uses
Windows Latin-1 as fall-back (not 8859-1, of course). Is that enough proof?

People using 7-bit ASCII do not see these issues, of course, but they
should trust 8-bit users when they say they are making their days.

The phrase that confuses you relates mainly the the former bug and a
wider class of character set issues. There are indeed more bugs than
this, but I obviously hesitate spending 2½ more year per bug.

Now, as a side note, please look at the Screenshot-2 attachment.
Does anyone really think it's possible to work with that Windows panel?
Hem, I finally found that the Windows List shrunk for no reason of mine,
but the tooltip continues to hide the list and that's a 2½ year old
problem too.
I see that you have been tracking this Bug #222267 too, thank you, and
that you added a Hardy tag. Should you no longer use Hardy, you may
give the problem a 2 min test, find that it still exists in the system
you use and add tags for all the systems in between, and that's most
probably up to Maverick.

I'd really appreciate not to repeatedly have to type more words than in
the questions and to say things only once, thank you.

Thank you for your attention.