Page MenuHomePhabricator

Dealing with non unicode aware browsers part 2
Closed, ResolvedPublic

Description

Author: plugwash

Description:
the resoloution to http://bugzilla.wikimedia.org/show_bug.cgi?id=2676 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.

w3m

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
http://en.wikipedia.org/w/index.php?title=Saint_Cyril&diff=prev&oldid=22770191

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

Details

Reference
bz3401

Related Objects

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 8:48 PM
bzimport set Reference to bz3401.
bzimport added a subscriber: Unknown Object (MLST).

sechinsic wrote:

client-side workaround .

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

Attached:

sechinsic wrote:

Comment on attachment 6222
client-side workaround .

from vim
:.,$!cat % | chr.wiki.py

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.