Akkana Peck Reporter
	Description • 22 years ago

Branched off from bug 162083:
delete word forward repeatedly, and you delete up to the space, then the space,
then up to the next space, etc.  Obviously it should get the space at the same time.

This doesn't happen on Windows, I'm told.  I strongly suspect this has to do
with assumptions selection is making about the value of the pref
"layout.word_select.stop_at_punctuation".

	Akkana Peck Reporter
	Comment 1 • 22 years ago

I bet this is the same issue as bug 142120.  See that bug for some hints on
where to fix it.

	Akkana Peck Reporter
	Comment 2 • 22 years ago

As mentioned in that bug: it's probably the
layout.word_select.eat_space_to_next_word rather than the one I mentioned
previously.  Word motion/deletion backwards works, but forward doesn't work right.

The code is in nsTextFrame.cpp and is interwoven with the bidi code; cc'ing bidi
experts since any fix for this will surely affect that code.

If anyone is willing to do a little test, I would be very interested to hear
what happens in bidi text when layout.word_select.eat_space_to_next_word is set
to false (as it is on mac and unix).  Does word motion take stop at spaces (i.e.
end of word, space, end of word, space) in one direction but not the other in
bidi text?  Does the direction that works right alternate?  Or do both
directions work the same?

	Akkana Peck Reporter
	Comment 3 • 22 years ago

One other question: the code in nsTextFrame.cpp is much more complicated for the
forward case than for the backward case.  Does anyone know whether there's a
reason for that?  Could they share most of that code, except for calling
tx.GetPrevWord vs. tx.GetNextWord according to the direction?

	Akkana Peck Reporter
	Comment 4 • 21 years ago

Mike's code (and related to other bugs on his plate).

	Uri Bernstein (Google)
	Comment 5 • 18 years ago

This was fixed back in April 2004, by the fix for bug 142120.