[Laszlo-dev] bug with multiline DHTML input text, and "bringToFront"?

[P T Withington]

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
> hminsky at laszlosystems.com