93192 - Typing LEFT-ARROW at beginning of INPUT wraps around to end

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P4)

Description

[Mats Palmgren (inactive)]

DESCRIPTION:
Typing LEFT-ARROW at beginning of INPUT wraps around to end.

STEPS TO REPRODUCE:
1. Load attached testcase (wich has further instructions.)

DOES NOT WORK CORRECTLY ON:
Mozilla nightly build 2001-08-01-03 on Windows 98 SE.

WORKS CORRECTLY ON:
Communicator 4.7 on Windows 98 SE.
IE 5.00 on Windows 98 SE.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 2

[Kathleen :Brade]

-->editor

Comment 3

[rubydoo123]

mjudge, 1.o

Comment 4

[Madhur Bhatia]

win2k build iD: 2001-09-28-05-0.9.4
macOS 10 -- build ID : 2001-09-28-04-0.9.4
RedHat Linux 7.1 -- build ID: 2001-09-28-04-0.9.4

The left arrow loops within the input text control when I do not have the 'size' 
attribute set and it is outside a table cell.

see the attached testcase.

--> HTML Form Control?

changing platform to --> all

Comment 5

[Madhur Bhatia]

Attachment: reduced test case

Comment 6

[Madhur Bhatia]

BuildID: 2001-10-17 (branch build)
with the above mentioned testcase :

1. if <input type=text> has a size attribute set and is outside a table cell --
 in win2000 & linux 7.1 ==> ctrl + left arrow loops within the control
 in macOSX ==> alt + left arrow loops within the control
 
 I noticed that left arrow does not loop within the control in this case.

2. if <input type=text> has no size attribute set and is outside a table cell --
 in win2000 & linux 7.1 ==> ctrl + left arrow loops within the control ; left
arrow also loops within the control
 in macOSX ==> alt + left arrow loops within the control ; left arrow also loops
within the control

Comment 7

[Madhur Bhatia]

*** Bug 69740 has been marked as a duplicate of this bug. ***

Comment 8

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 9

[TucsonTester3]

This is a major issue and is still happening with build 2002020103, adding
keyword nsbeta1

Comment 10

[Syd Logan]

nominating EDITORBASE

Comment 11

[TucsonTester3]

*** Bug 124172 has been marked as a duplicate of this bug. ***

Comment 12

[Kevin McCluskey (gone)]

Marking EDITORBASE+

Comment 13

[Tom Mraz]

Note that there is a fix by Shotaro Kamio in the bug 82151 which fixes this as well.
The fix needs r/sr/a

Comment 14

[mjudge]

I have changed the patch slightly.  This change will allow the leaf iterator to 
not ALWAYS stop at scroll frames.  One reason would be for scrollable table 
cells where you want to be able to arrow out of the cell.  I added a parameter 
to the PeekOffsetStruct that gets passed to the NS_NewFrameIterator call.  

Comment 15

[Shotaro Kamio]

mjudge, would you tell me what should I do or not in my patch for Bug 82151?

Comment 16

[Jaime Rodriguez, Jr.]

Is this really a Minor/P4 bug? If so, is this really an ADT1. ADT2 per ADT triage.

Comment 17

[mjudge]

Attachment: patch to pass in parameters to stop iterating when we hit a scroll view

this allows us to decide when to stop traversing the frame tree if a scroll
view is hit.

Comment 18

[mjudge]

marked as fixed branch and trunk

Comment 19

[saari (gone)]

adding fixed1.0.0

Comment 20

[michael wendell]

Verified on the 05-07 trunk and 1.0.0 branch builds.

Comment 21

[Dawn Endico]

removing item for this bug from the release notes since the bug is marked
fixed. If this is in error, please make a note in the release notes bug for
the current milestone. As of today, this is bug 133795. In a ew weeks, it 
will be some other bug.