incorrect body content shown

Bug #981849 reported by tbnorth
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
leo-editor
Fix Released
Critical
Edward K. Ream

Bug Description

I don't know if this is related to https://bugs.launchpad.net/leo-editor/+bug/979142 or not, so I'm opening new.

bzr revno = 5254, Ubuntu 11.10, Python 2.7.2
Leo 4.10 final, build 5254, 2012-04-14 13:59:11
Python 2.7.2, qt version 4.7.3

It's basically http://groups.google.com/group/leo-editor/browse_thread/thread/af340567c672290d?fwc=1

Here's what I just did. In the shell, `history >log` creating a numbered history of recent shell commands. The numbers are sequential incrementing by one each line.

I then loaded the file 'log' into Leo using my command line leoserver script, which I'm sure is completely innocent - it's always worked fine before. Here it is, anyway:

    #!/usr/bin/python
    import sys
    sys.path.append("/home/tbrown/Package/leo/bzr/leo.repo/trunk")
    from leo.external import lproto
    import os

    addr = open(os.path.expanduser('~/.leo/leoserv_sockname')).read()
    pc = lproto.LProtoClient(addr)
    pc.send("""
    import os
    fn = %s
    c = g.app.commanders()[0]
    h = "@edit "+fn
    n = g.findNodeAnywhere(c, h)
    if not n:
        n = c.rootPosition().insertAfter()
        n.moveToRoot(c.rootPosition())
        n.h = h
        if os.path.isfile(fn):
            n.b = file(fn).read()
    c.selectPosition(n)
    c.redraw()
    c.bringToFront()
    """ % repr(os.path.join(os.getcwd(), sys.argv[1])) )

Then I switch to the Leo window, and the attached before.jpg is what I see, the file without all the lines showing (numbers not uniformly increasing by one), which makes no sense. I click away from and back to the node, and I see the attached after.jpg, the expected content.

I don't think the convuluted way I reached this point is to blame, I've been seeing this frequently lately, but because it dissappears when moving off the node, it's hard to repeat. The above did work for me twice in a row.

Also I'm seeing F3 find-next scroll the body pane but show no highlighted hit and no visible target text, I think tha's the same bug, also goes away after switching nodes. Hard to reproduce though.

Revision history for this message
tbnorth (terry-n-brown) wrote :
Revision history for this message
tbnorth (terry-n-brown) wrote :
Revision history for this message
tbnorth (terry-n-brown) wrote :

This continues to show up with

Leo 4.10 final, build 5258, 2012-04-16 08:56:47
Python 2.7.2, qt version 4.7.3
linux2

Attached are view0/1/2.jpg

0 and 1 are in a @shadow node even after refresh from disk, and exiting and restarting Leo, it won't display properly. 2 is correct, in an edit node.

Changed in leo-editor:
assignee: nobody → Edward K. Ream (edreamleo)
Revision history for this message
tbnorth (terry-n-brown) wrote :
Revision history for this message
tbnorth (terry-n-brown) wrote :
Changed in leo-editor:
status: New → Fix Released
importance: Undecided → Critical
Revision history for this message
Edward K. Ream (edreamleo) wrote :

This is one of the strangest bugs I've ever seen. After extensive research, I can see nothing obviously wrong with Leo's code, but clearly something was wrong somewhere.

Rev 5259 fixes this bug, apparently, by having v.restoreCursorAndScroll always call setSelectionRange with "full" parameters, that is, by explicitly specifying the "insert" argument. This fixes the reported symptoms, but it is still unclear what was going on.

Extensive testing showed that at no time was data ever lost, even though body text was incorrectly rendered. It's possible that somehow setting the insert point while leaving the selection range as it was somehow confused the *Qt* colorizing code, but it is fairly clear that at no time did *Leo's* colorizing code ever become confused.

g.restore_selection_range has been removed. It was only ever used in v.restoreCursorAndScroll.

Revision history for this message
Edward K. Ream (edreamleo) wrote :

Somehow rev 5259 was lost. This was a happy accident, because the new fix make more sense.

Here is the checkin log for rev 5262:

Fixed bug 981849: "incorrect body content shown": leoQTextEditWidget.setInsertPoint now uses more careful code in setSelectionRangeHelper

Also removed g.restore_selection_range.

All unit tests pass.

Changed in leo-editor:
status: Fix Released → Confirmed
milestone: none → 4.11-b1
Revision history for this message
Edward K. Ream (edreamleo) wrote :

Unless somebody knows more about this problem, I am going to assume it has been fixed.

You you reopen this item, please provide full details about how to recreate the problem.

Changed in leo-editor:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.