Closed Bug 191701 Opened 23 years ago Closed 17 years ago

'Encoding:' shows charset used by Mozilla - not original encoding of page

Categories

(SeaMonkey :: Page Info, defect)

Product:
SeaMonkey
Component:
Page Info
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mikus, Assigned: db48x)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3b) Gecko/20030201 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3b) Gecko/20030201 If the charset to be used for a page is __not__ supplied by either the HTTP header nor by the HTML <HEAD>, Netscape 4.61 (OS/2) shows 'Encoding: Unknown' Mozilla, instead, shows its default character coding, or whichever character coding was most recently specified via View/Character Coding for that page. It is confusing to the user that the Mozilla 'Page Info' lists the charset it is currently using to display the page, rather than the charset information as known to the depository from which the page was fetched. Reproducible: Always Steps to Reproduce: 1. View the page identified in the URL above. 2. Look at View/Page Info. It will say the page is encoded in whatever the current profile default character coding is. 3. Go to View/Character coding and select any different-looking charset. 4. Now look again at View/Page Info. It will say the page is encoded in that newly-selected character set. Actual Results: The character set in which that page was originally encoded did NOT change. Yet from looking at View/Page Info, the user is led to believe that the encoding of the page has changed (when it is only the encoding used for the display presentation that has changed). Expected Results: If neither the server nor the HTML have indicated the original charset used to create the page, View/Page Info should show that the page encoding is unknown. If Mozilla wants to replace 'Encoding: Unknown' with a locally-generated value, it should flag that field to show that a substitution has been made.
OS: other → OS/2
Not Os/2 specific
OS: OS/2 → All
Hardware: PC → All
Status: UNCONFIRMED → NEW
Ever confirmed: true
Why not modifying the "Page Info" dialog with something more explicit: HTTP Server encoding: none received Actual encoding used: XXXXXXXXXXXXX I think the new line ("Actual encoding used:") could be only displayed when necessary i.e. when there is a problem like: - when there is a conflict between HTTP header and the page's Meta tag (bug 190367) - when the HTTP header is invalid (bug 124548) and no Meta tag is present - when there is no HTTP header and no Meta tag in the page - when the Auto-detector is used - in all these cases when the page is reloded from the cache - ... Since there is quite a few open topics on Character encoding questions (as shown on http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html), giving a kind of feedback in the "Page Info" on what is hapenning on the page would be a great addition.
Is anything happening on this now? As it now stands, there's no way to check on whether a page is received with a proper charset via Mozilla; I need to use external utilities every time I want to check on this. The use of the "default charset" in the Page Info window is very misleading, and might lead some Web authors to think their own pages correctly set character encodings when in fact they do not.
Product: Browser → Seamonkey
QA Contact: pmac
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
WONTFIX: See the following post in mozilla.dev.apps.seamonkey: http://groups.google.com/group/mozilla.dev.apps.seamonkey/browse_thread/thread/722358827994743a/5b76454811bb342d
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.