Closed Bug 22580 Opened 26 years ago Closed 26 years ago

form text remember any non Latin1 char as '.'

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 29154

People

(Reporter: ftang, Assigned: ftang)

References

(
URL
)

Details

(Whiteboard: fix available - see 29154. reviewed. Wait for a= from rickg)

pollmann- is this your area ? 1. Go to any URL which accept form text input, such as http://home.netscsape.com/ja 2. type some Latin 1 and non-latin1 text and submit 3. Click "back" 4. The Latin 1 text in the form text field will be remember, but the non latin1 part will be remember as '.' instead.
Note that depending on which search engine page you use, you might see only the blank field (i.e. nothing) when the Back button is pressed. Yahoo Japan and Netscape Japan pages are are like this: http://www.yahoo.co/jp/ but Lycos Japan page returns dots for Japanese characters. http://www.lycos.co.jp/ In any case, we should be seeing the original input in all of these cases instead of dots or blanks.
Status: NEW → ASSIGNED
Target Milestone: M13
Yes, this is probably a bug in the frame state storing or retrieval code. I'll take a look, thanks!
Correction on URL. Yahoo Japan Page is: http://www.yahoo.co.jp/
Target Milestone: M13 → M14
Moving to M14, guessing I won't be able to get this in tomorrow.
** Update with 1/27/00 Win32 M14 build ** Now I see simply a blank form field with all the above search URLs when I press the Back button. And it does not have to be a non-ASCII input. ASCII input also has the same problem.
The form inputs not being remembered at all is bug 13537. I'm marking as a dependency as we need that fixed before we can work on this.
Depends on: 13537
Moving non PDT+ bugs out.
Target Milestone: M14 → M15
I think part of the cause is bug 29154. Mark 29154 as blocking this.
Blocks: 29154
Blocks: 28019
No longer blocks: 28019
Bug 13537 was fixed on 2/11. We should retest and update this bug report. cc'd roberts to get opinion on need for Beta1. If users are shopping or requesting info and clicking through 1 or more forms, often they need to go back and enter missing or erroneous data. How important is this for Beta1?
This is important to report non ASCII related bug by using SeaMonkey with Bugzilla. If intl users using SeaMonkey to report bug on Buzilla and put down some non ASCII text, and he jump to other page to collect some data, when he return, the non-ASCII part will trun into ... . Put beta1 keyword into this.
Keywords: beta1
Depends on: 29521
No longer blocks: 29154
Depends on: 29154
Marking PDT- for beta1. It's getting too late to go for these.
Whiteboard: [PDT-]
This might be a dup of bug 29521.
this is not a DUP of 29521. IT is DEPNEND on 29521. You need to fix 29154 first before this get fix.
remove [PDT-]. sfraser already fix 29521. Please consider this PDT+ again. We need to fix 29154 first to fix this since that bug is ONE of the reason which trash the data.
Whiteboard: [PDT-]
Assignee: pollmann → ftang
Status: ASSIGNED → NEW
Whiteboard: fix available - see 29154.
It turn out it is a DUP of 29154 AFTER 29521 fixed. I have a fix now. See 29154 for the patch. Reassign this to ftang. pollmann, please review the code. Thanks.
Reviewed - looks good to me!
ready to check in . need rickg's approval
Status: NEW → ASSIGNED
Whiteboard: fix available - see 29154. → fix available - see 29154. reviewed. Wait for a= from rickg
per PDT, if rickg approves, go ahead and check in.
*** This bug has been marked as a duplicate of 29154 ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
VERIFY duplicate
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.