13665 - [regression] keyboard-based extended selection broken

Status: RESOLVED WORKSFORME

(Core :: DOM: Selection, defect, P1)

Description

[buster]

open example 0 in either the browser or editor
put the caret in between 'o' and 'n' in the word "Fo^nt" in the text "Font
point-size=24"
shift-arrow left several times
notice that you can't select past the space just prior to the word "Font"
Selection unexpectedly snaps back to the middle of the word "point."

start over, this time shift-arrow to the right.  This time, you can get all the
way to the first 'T' in "This Text Is Small-caps"  Then the selection collapses
back to where it started.

Comment 1

[mjudge]

fixed thanks! batter up..

Comment 2

[Eli Goldberg]

I'm re-opening this bug, after checking the 1999 10/1 builds on Win NT 4.0SP5,
Mac OS 8.6, and RH 6.0/GNOME.

Specifically, it says, "open example 0 in either the browser or editor". However,
in this build, keyboard-based text extension does not work within the browser;
only within the editor.

Within the editor, downwards-pointing keyboard selection extension ceases to
operate after reaching the "This paragraph is justified..." paragraph.

Comment 3

[mjudge]

this has been fixed in the build on the tip.

Comment 4

[Eli Goldberg]

All issues for which bug was re-opened are still present in all builds checked:
	1999100708 Mac OS & Linux
	1999100708 Win32

Thus, re-re-opening.

Comment 5

[leger]

Workaround is to redrag select...not a dogfood stopper.  PDT-

Comment 6

[mjudge]

ok elig THIS time its fixed ;)

Comment 7

[Eli Goldberg]

Verified fixed 1999102008 Mac OS and 1999101908 Win32 build. (Per mjudge,
keyboard-based extended selection should only work within Editor, not within
Browser.)

Verification on Linux blocked by 16795; will formally mark as verified when fix
is in builds.

Comment 8

[Eli Goldberg]

Re-opening; verification failed on Linux (1999102508 build, RH 6.0/GNOME). To
reproduce, follow steps of original bug report.

Comment 9

[rubydoo123]

shifting over to M12

Comment 10

[Eli Goldberg]

per beppe's request ---

Still busted using this morning's Linux build; text selection halts after "T" in
Text styles. Also busted on Mac. Didn't check Windows. (I'd go into more detail,
but I'm sure mjudge doesn't need it.)

Comment 11

[rubydoo123]

updating summary fields, removing PDT- and [dogfood], adding [regression]

Comment 12

[mjudge]

fixed. as of today

Comment 13

[Eli Goldberg]

Verified fixed using:
	200011310 Mac OS
	200011308 Win32

However, using the 200011308 Linux build, keyboard selection extension doesn't
work at all. Therefore, re-opening.

---

There are also two side-issues; will poke into these further and add $.02 into
this bug report:

#1: The last character is not selectable; it'll select, and then unselect.

#2: On Win32, the selection is updated very infrequently; often as much as once
per paragraph or per line.

Comment 14

[rubydoo123]

moving this to m14

Comment 15

[mjudge]

checked this on elig's machine. seemed ok. please recheck. thanks

Comment 16

[Eli Goldberg]

Verification blocked by 25730.

Comment 17

[Eli Goldberg]

Verification now blocked by 13665. ;)

Comment 18

[Eli Goldberg]

Duh, meant 28734.

Comment 19

[Eli Goldberg]

[Split out a side issue into bug #29567, "Select styled text by keyboard
shortcut --> munged selection"]

Comment 20

[Eli Goldberg]

[Split out a second side-issue into bug #29580, "First letter frames handled
improperly with hit testing or keyboard navigation"]

Comment 21

[Eli Goldberg]

Marking verification dependent upon 29580.

Comment 22

[Blake Ross]

*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
[e-mail] to [e-mail].  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...