That rules out my theory that it is the change from INPUT to TEXTAREA,
but there must be some skew between what the inputsprite does for an
INPUT vs. TEXTAREA when it creates them. If you recall, earlier when
the cursor was wrong for single-line input's, it was right for
multiline. Now it seems we have fixed single and broken multi?
Question: Why do we use two different DOM elements? Can't we have a
TEXTAREA that is only 1-line high?
On 2009-09-14, at 18:16, Henry Minsky wrote:
I'm debugging LPP-8419, where you cannot type into the debugger's
input
field when it is in multiline mode.
The actual bug is in this test case
<view onclick="this.bringToFront()">
<inputtext bgcolor="#cccccc"
multiline="true" width="300" height="100" >this is
input
text</inputtext>
</view>
If you have a view which brings itself to front when you click in
it, and it
has a multiline text field, then
you cannot type into the text field. I am wondering if the
"bringToFront" is
leaving the div tree in some
inconsistent state, where the actual input div is getting left
underneath or
something.
I'm going to look at the DOM objects to see if I can figure out
anything
from the z indexes or something,
but was wondering if it was obvious to you what might be causing
this bug?
--
Henry Minsky
Software Architect
[email protected]
