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.

-->editor

mjudge, 1.o

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

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

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

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)

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

nominating EDITORBASE

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

Marking EDITORBASE+

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

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.

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

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

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

marked as fixed branch and trunk

adding fixed1.0.0

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

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.