Hi Roger,
I've created LPP-8893 [1] to track this issue. It's caused by a Flash
internal bug, we need to figure out how to create a workaround.
- André
[1] http://jira.openlaszlo.org/jira/browse/LPP-8893
Roger Yarrow wrote:
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>
>
