Seen on trunk, 10/16. Run composer. Type <accel-i>Hello <accel-i>world (accel-i = hold down the accelerator modifier and i, to toggle italics) Type five backspaces; the letters of "world" progressively disappear. Type another backspace, expecting the space between Hello and world to disappear; instead, the whole word Hello is deleted.
I saw this on a Macintosh debug build from yesterday morning (pressing delete appropriately deleted text and then a whole link with one keypress).
this is not good, i would think that would be considered dataloss, marking as such
hummina hummina hummina
i cannot reproduce this. Will mark WORKSFORME unless someone says they can reproduce it.
The problem seems gone in the current trunk (will try branch next).
Problem is still there on the branch.
hmm, i cannot reproduce it on my branch build.
i checked with Akkana: she didn't actually see this happen as described here. Rather, she saw some case she cant quite remember. If anyone finds a way to reproduce this, let me know.
Apparently it's gotten harder to reproduce. I can't reproduce it using the steps described in the bug; I saw it this morning when editing a mail message. (which means it probably still happens on the trunk, too.) I was in html mail compose, I copied a bunch of plaintext quotes one-by-one from another window, then selected them all and made them preformatted (I really wanted plaintext compose but wasn't able to get it from the browser window), then did a lot of editing of line ends to stick them all together and fix the line lengths (since they all ended up in separate pre's), then started adding comments between the various plaintext-quoted blocks. I saw the bug when I started deleting my own remarks back to the beginning of a section, overshot and deleted into a quoted block -- which deleted the whole quoted block. If I find a cookbook way of reproducing it, I will describe it here.
i found a way to get this to happen. use the original test case EXCEPT, left arrow once before deleting. investigating bug now...
fix in hand; attaching next
the patch is simpler than it looks: basically, an if/elseif/else clause has been reordered. This has happenedin two places in the same routine, for two nearly identical if/elseif/else clauses. One is for backspace, the other forward delete. We now test for text nodes *before* checking for non-containers, since text nodes are not considered containers by the dtd.
The patch looks good. As long as there is some serious bashing on this (lots of typing testing), sr=sfraser
The change is very straightforward, makes sense, and does indeed fix the problem. r=akkana.
I'm not sure if this is right or not, could someone test deleting around lists and tables? I'm seeing some funkiness which may or may not be related to this patch.
i haven't found any differences caused by the patch. There are some unrelated oddities that are less serious and that are independent of this patch.
yes, Joe is right; the problems I see are unrelated to this patch. I have filed a different bug on those issues. Setting to rtm+ for Joe.
PDT marking [rtm need info]. Does this only happen if you use the accelerators, or is there a simpler way to see this? Since the patch is large-ish for this state of the branch, please check into the trunk and get help from editor QA to verify that there aren't any regressions. After that, please mark rtm+ again for consideration.
Joe, push this through getting into the trunk, and pass on the branch.
beppe: Does your comment mean that this should fall off of the rtm radar?
PDT marking [rtm-] since that seems to be what beppe intended.
this will definitely land for 0.8
this problem is fixed. however a new problem is discovered. filing separate bug