On Mon, Sep 14, 2009 at 6:41 PM, P T Withington <[email protected]> wrote:
> 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? If you have a one line high textarea, can you make it so that when the user enters a newline that it is ignored, or asking another way is there a way to restrict a text area to a maximum of one line of input? > > > 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] >> > > -- Henry Minsky Software Architect [email protected]
