Tags:
create new tag
, view all tags
Got a report that the Opera browser on Linux doubles each end of line on topic save, thus damaging tables and numbered lists. Preview is fine. Opera Browser version 5.0b7.

-- PeterThoeny - 10 Apr 2001

It turned out that the Opera browser sends formdata with odd "\r\r\n" line endings to the preview script.

Fix: Add red lines at the end of preview

    $text =~ s/&/%_A_%/go;
    $text =~ s/\"/%_Q_%/go;
    $text =~ s/>/%_G_%/go;
    $text =~ s/</%_L_%/go; 
    # PTh 10 Apr 2001: Fix for Codev.OperaBrowserDoublesEndOfLines
    $text =~ s/\r\r\n/%_N_%/go; 
    # PTh 21 Jun 2000: Fix for Codev.KfmBrowserSupportForEditing
    $text =~ s/\r\n/%_N_%/go;
    $text =~ s/\n\r/%_N_%/go;
    $text =~ s/\r/%_N_%/go;
    $text =~ s/\n/%_N_%/go;

Commited changes to TWikiAlphaRelease

-- PeterThoeny - 10 Apr 2001

This still doesn't seem to fix things for me. Right now on this server on Opera (LInux 5.05) I find that every line in this edit window has a extra "space" at the end of the line. I suspect this is the \r that in put in the text sent to the edit window. So when I copy it back we get the \r\r\n on all the existing lines.

However if I edit the existing lines it is very easy to get that space in a place I don't want it.

Is there a reason we have to look at the \r's at all? Do any browsers return a \r without a \n at the same place? Machintosh maybe? If not, then just stripping all \r's before looking for \n's would seem to fix the problem.

-- WayneScott - 14 Nov 2001

Ouch!

That didn't work. The preview worked find but my previous edit double spaced every line. For this one I tried to delete all the extra lines and all the magic "spaces" at the end of every line. Lets see if that works. If it doesn't then someone else will have to clean this topic. Sorry!

-- WayneScott - 14 Nov 2001

Since you are using Opera, have a look at RefreshEditPage, which causes the first set of edits to be lost when re-editing a page in the same session. Fortunately there is a good patch for this - maybe you could comment in AthensRelease if you'd like this in the next release.

-- RichardDonkin - 19 Nov 2001

Actually, Opera just adds \r\n at the end of the lines. So, if you add by hand to the file \r\r at the end of a line, opera sends back a \r\r\r\n, etc... So the solution may be actually to replace ALL encodeSpecialChars by:

sub encodeSpecialChars
{
    my( $text ) = @_;
    
    $text =~ s/&/%_A_%/go;
    $text =~ s/\"/%_Q_%/go;
    $text =~ s/>/%_G_%/go;
    $text =~ s/</%_L_%/go; 
    # A newline is \n or \r following any number of \r or \n
    $text =~ s/\r*\n/%_N_%/go; 
    $text =~ s/\n*\r/%_N_%/go;

    return $text;
}

-- ColasNahaboo - 19 Nov 2001

Note that the above technique won't work. It will eat empty lines by condensing strings like \r\n\r\n into a single newline.

I think the best course is to just eliminate all carriage returns. My rudimentary Perl knowledge says that this could be implemented like this:

sub encodeSpecialChars
{
    my( $text ) = @_;
    
    $text =~ s/&/%_A_%/go;
    $text =~ s/\"/%_Q_%/go;
    $text =~ s/>/%_G_%/go;
    $text =~ s/</%_L_%/go; 
    $text =~ s/\r//go; 
    $text =~ s/\n/%_N_%/go;

    return $text;
}

-- JoachimDurchholz - 20 Nov 2001

Yes, the problem was still there (I never used opera for wiki due to these problems, I only checked back recently). Actually the fix on top of page fix the common case but may not fix the case where you would have \r\r\n, which happens as opera blindly adds \r\n to ends of lines, so repeated edits can lead to this situation. And my fix works, as you can see on my prototype site (not yet operational, but feel free to play in the Test web: http://koala.ilog.fr/wiki/bin/view/Test/WebHome

My code aims to convert single \r without \n into newlines. but perhaps this does never happen (macintosh?). Your code works, too, if we suppose no browser sends %0D alone as end-of-line.

If anybody has a macintosh, please test: http://koala.ilog.fr/cgi-bin/doublelinesbug

-- ColasNahaboo - 20 Nov 2001

Hmm... right.

My code will just eat all line ends if some insane Macintosh browser sends just \r as an end-of-line marker. Not good.

I diagnosed your code incorrectly (relied on the comment, didn't properly read the code - sorry).
It's still wrong though - it will not condense \r\r\n into a single newline.

I think the situation requires an asymmetric approach; an end-of-line is an arbitrary number of \r, followed by a \n, or a single \r. In other words:

  \r*\n|\r
This should work since regexps are generally "greedy", i.e. prefer a longer match over a shorter one; \r\r\r\n will match \r*\n instead of just \r since this will eat more characters from the input string.

This gives me:

sub encodeSpecialChars
{
    my( $text ) = @_;
    
    $text =~ s/&/%_A_%/go;
    $text =~ s/\"/%_Q_%/go;
    $text =~ s/>/%_G_%/go;
    $text =~ s/</%_L_%/go; 
    $text =~ s/(\r*\n|\r)/%_N_%/go; 

    return $text;
}

-- JoachimDurchholz - 21 Nov 2001

This seems to be the best solution. I installed it, and it seems to work quite well.

-- ColasNahaboo - 22 Nov 2001

Joachim, sounds like a good fix. Is now in TWikiAlphaRelease and TWiki.org.

-- PeterThoeny - 22 Nov 2001

Sorry if this is the wrong place to raise this... I'm not really objecting to this Bug resolution. I'm using 20011201 release (with the above fix), on Linux. My question is simple - why do my TWiki data/ files have a CR/LF at end of each line in the first place? I'd prefer to choose the text file format based on my choice of OS so in my case would just have LF. Could someone tell me if it was just a historical compatible-with-Dos-files-too decision or some other reason? Could a future release allow the choice?

[background for those who care: I'd really like my TWiki data text files to be native so that live content interaction at the Unix level doesnt have to do any translations. For example, I insert some new content in a page programmatically, (with LF's, not CR/LF's) and next time the page is edited, the combination of the Opera fix above and decodeSpecialChars() alters that content to add CR/LFs, leaving my MD5-Digest processing in a muddle]

-- GordonAllan - 08 Oct 2002

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2005-02-15 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.