Closed Bug 28019 Opened 25 years ago Closed 24 years ago

Form POST method fails with charset <> iso-8859-1

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 27006

People

(Reporter: spiros_ioannou, Assigned: ftang)

References

(
URL
)

Details

Hello, Form POST method fails when the charset is for example iso-8859-7. By charset I mean the value of: <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-7"> in the <head> </head> section The problem may reside in the renderer because the page is displayed instantly in 8859-1 encoding and then it is instantly reloaded in the correct encoding without the post variables posted. You can find an example there: http://venizelos.image.ece.ntua.gr/php/tests/formtest.php Enter something in the box and press submit. The value entered will normally exist in the box after the submit, but not with mozilla. In my case the box reappears empty. The problem dissapears if I remove the <meta ...charset=...> tag from the html. The php used is elementary. Follow the link to see the source. This bug also exists in the solaris version, and existed in previous milestones. The millestone tested is M13 At your disposal for further information, Spiros Ioannou sivann@cs.ntua.gr
Reassigning to Warren.
Assignee: karnaze → warren
=> valeski
Assignee: warren → valeski
Target Milestone: M15
over to ftang. Frank, It looks like we're not sending the charset back to the server http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/forms/src&command=DIFF_FRAMESET&file=nsFormFrame.cpp&rev2=3.33&rev1=3.32 I suspect this is that fun bug where we're damned-if-we-do or damned-if-we-don't.
Assignee: valeski → ftang
valeski- No, this is not realted to the sending charset back problem. The rendering issue is about meta reload. It should be gone now. >The value entered will normally exist in the box after the submit This is related to the bug that we currently do not remember form value after post (see bug 13537) and non ASCII string currupted when they try to remember it (see bug 29154 22580)
Depends on: 22580, 29154
sorry, my early analysis is wrong. The problem is not related to those bug. It is because we do a meta reload which clean up the setting. If user set the default charset to ISO-8859-7 then the problme go away. This bug is because we do a reload when we hit the meta tag. Maybe we should do a "Peek" in the first block to reduce the chace of reload.
Status: NEW → ASSIGNED
No longer depends on: 22580, 29154
We should consider adding "peeking" code into parser to get charset info to reduce the need of meta charset reload.
jbetak, can you help to fix this ?
Assignee: ftang → jbetak
Status: ASSIGNED → NEW
sorry- wrong bug.
Assignee: jbetak → ftang
Status: NEW → ASSIGNED
Mark this M19. Move the serverity to normal since it only break this test case.
Severity: critical → normal
Target Milestone: M15 → M19
OS: Linux → All
Hardware: PC → All
I just got a "complaint" today, and it seems it doesn't only break the test case, because this guy brought another case, and I think there will be yet many more forms which will be affected, namely really all which are not with ISO-8859-1 Charset... URL: http://www.mitf.f2s.com/encoder.php3 [raising severity to major]
Severity: normal → major
form posting and charset conversion / handling issue. Reassign to jbetak and cc cata
Assignee: ftang → jbetak
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
reassigning to ftang for resource reallocation
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
assign untill find new owner for form handling
Status: NEW → ASSIGNED
In my case Mozilla (2000070220) does not POSTs values at all. Changing method from POST to GET resolves problem, but this is not right way to solve this problem.
The meta charset reload is the problem here, it doesn't repost form data. *** This bug has been marked as a duplicate of 27006 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Updating QA contact.
QA Contact: ckritzer → vladimire
Verifying duplicate
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.