Dealing with non unicode aware browsers part 2
Closed, ResolvedPublic


Author: plugwash

the resoloution to dealt with
the IE mac which it seems was more of a problem than all the others combined.
However I'm still getting sporadic reports of problems. and some of them are
more complex cases than IE mac was ;)

netscape 4.x

unable to edit unicode properly on any platform i've 
tried it on. The difficulty here is making a regexp 
to identify all subversions of it without matching 
stuff that declares itself as compatible with it

lynx and links

these convert to the local charset (links apparently 
only when in text mode) if the local charset is utf-8
then they are fine if it isn't they currupt unicode.


similar to lynx and links but doesn't currupt the text
until its actually edited meaning dummy edit boxes can't
be used to identify if its in a problem mode.

I also have a strange bad edit report for which the browser has not yet been
identified see

Ideas on how to proceed.

allow users to manually enable and disable safe mode editing 
in preferences (with default being to base on blacklist).

for lynx and links detect by a dummy edit control on login form

add netscape4 and w3m to blacklist

any comments on these ideas welcome.

Version: 1.6.x
Severity: major

bzimport set Reference to bz3401.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Sep 8 2005, 10:20 PM

sechinsic wrote:

client-side workaround .

Python3 script . Recommended use : Lynx session, external editor vim, :.,$!cat % | ./ .


sechinsic wrote:

Comment on attachment 6222
client-side workaround .

from vim
:.,$!cat % |

plugwash wrote:

netscape 4.x was added to the blacklist some time ago. The other browsers don't seem to be causing any problems in practice (I guess the number of users trying to edit from text mode on non utf-8 unix systems is minimal) so this can probablly be closed.

see above comment

Add Comment