My test case doesn't show it but I was using inputtext with enabled="false"
so input wasn't a factor. I guess in these situations I'll just use text...
I was working with scrollinputtext class when I noticed this behavior so
thought I'd mention it.  When I inspect an inputtext, I don't see anything
"deeper" within it (innertext, markup) unless it is all hidden inside the
TextSprite thing.

On Fri, Apr 9, 2010 at 12:14 PM, P T Withington <[email protected]> wrote:

> I have to suspect the effect you are seeing is because selecting an input
> text only selects the inner text and not the markup so the markup persists.
>
> But I wonder what the purpose of having HTML in an input element is, since
> there is no input gesture that will let you input HTML?  What are you
> expecting?
>
> As to whether to select the entire content, I think it has become accepted
> that when you initially select an input element, the entire content should
> be selected.  This is contrary to Apple UI guidelines which say you should
> place the cursor at the point nearest to the mouse click, but it is
> apparently the Microsoft UI (and is creeping into OS X through Firefox).
>  Not that I like this, but I think it has become the /de facto/ standard.
>
> On 2010-04-09, at 11:29, Roger Yarrow wrote:
>
> > This is occurring in OL 4.7.1 swf9/10.  I searched JIRA for a bug but
> > couldn't seem to find a match for this situation.  Are users supposed to
> > just enter bugs directly into JIRA or post here first?  :)
> >
> > The issue is that inputtext, once clicked or selected, gets all screwy
> with
> > drawing HTML.  Once clicked/selected, all text is rendered improperly and
> > cannot be recovered -- meaning it is always drawn wrong no matter how
> many
> > times you set the text.
> >
> > Run the test program.  Just click each button back and forth as many
> times
> > as you want and the HTML will render properly.  Next, click inside the
> > inputtext (focus) and/or select text within it.  Then click one of the
> > buttons -- when the text updates, ALL the text will forever be displayed
> > underlined or bolded depending upon which tag was in use at the time of
> the
> > click.  So, if you click Bold and then select from the inputtext, click
> > Underline, and all your text is bolded.  Reload the app, perform the same
> > feat on Underline, and all your text will forever be underlined.
> >
> > If I set the inputtext selectable="false" the problem still occurs.  You
> > click on the text, it selects it ALL (which I think is another bug?) and
> > then the HTML rendering behavior appears.
> >
> > <canvas width="100%"  debug="true" height="560" >
> > <simplelayout axis="y" spacing="10"/>
> > <button>Bold
> >    <handler name="onclick">
> >        <![CDATA[
> >            test.setAttribute('text','<b>Here is bold</b><br/><br/>And
> this
> > should be plaintext<br/><br/><b>And bold again</b>');
> >        ]]>
> >    </handler>
> > </button>
> > <button>Underlined
> >    <handler name="onclick">
> >        <![CDATA[
> >            test.setAttribute('text','<a href="#"><u><font
> > color="#0000ff">Here is a hyperlink</font></u></a><br/><br/>And this
> should
> > be plaintext');
> >        ]]>
> >    </handler>
> > </button>
> > <inputtext width="300" height="200" id="test" multiline="true"
> > oninit="this.setHTML(true)"/>
> > </canvas>
>
>

Reply via email to