[Laszlo-dev] For Review: Change 20090727-maxcarlson-U Summary: UPDATED: Don't re-parent input text to click tree

[P T Withington]

If you look at the bug attachments, I tried to build a test case in  
straight DHTML that would forward mouse events and it fails miserably.

I think we are coming full-circle here to my original discussion where  
I tried to evaluate which was more important:  a) faithfully  
implementing the swf click model, or b) faithfully rendering the swf  
view compositing model.

It seemed most people would rather have "looks good" than "clicks  
good".  Nobody liked the text bleeding through 'feature'.

It's too bad we were led down the garden path by swf's click model.   
Is it _really_ the case that "this kind of code appears all over  
webtop" per your example below, or is this a specific test case that  
is actually implemented by a core class in webtop (and hence might be  
easily re-engineered to use a different compositing choice)?

On 2009-07-27, at 21:25EDT, Max Carlson wrote:

> So, Maynard and I tested this on webtop today, and it works in most  
> cases.  It falls down when a field is programatticaly focused - this  
> causes the click tree to be hidden, so the mouse doesn't work until  
> the inputtext is moused over and out.  I was able to fix this by  
> checking the target div for the global mousemove event - if it's not  
> an inputtext, I __hide() the one that's currently showing
>
> The other (thornier) thing I can't figure out is how to deal with  
> views in front of an inputtext.  This simple testcase fails.  I was  
> able to work around a case with the animated focus brackets  
> preventing text selection, but this kind of code appears all over  
> webtop:
> <canvas>
>    <inputtext>Can't select or click because we're covered by another  
> view</inputtext>
>    <view width="100%" height="100%" bgcolor="red" opacity=".2"/>
> </canvas>
>
> So, do we go back to reparenting and accept the degenerate case  
> where inputtext can be floating on top of everything?  I'm not sure  
> how to:
> a) detect there's an active inputtext behind the lzdiv and b)  
> forward the mouse event there...
>
> Anyone have any ideas there?  Otherwise, webtop will need to somehow  
> prevent views from floating over inputtexts - in all cases.
>
> On Jul 27, 2009, at 4:25 PM, Max Carlson wrote:
>
>> Change 20090727-maxcarlson-U by maxcarlson at Bank.local on 2009-07-27  
>> 16:21:22 PDT
>>   in /Users/maxcarlson/openlaszlo/trunk-clean
>>   for http://svn.openlaszlo.org/openlaszlo/trunk
>>
>>
>> Summary: UPDATED: Don't re-parent input text to click tree
>>
>> Bugs Fixed: LPP-5447 DHTML: inputtext and clickable
>>
>> Technical Reviewer: ptw (pending)
>> QA Reviewer: a.bargull at intensis.de (pending)
>>
>> Details:
>>  This is based on Tucker's change (http://svn.openlaszlo.org/openlaszlo/patches/20090722-ptw-k.tar 
>> ).  I turned off the dom_breaks_focus quirk for firefox, cleaned up  
>> LzMouseKernel to not attempt to re-focus inputtexts when showing  
>> the click tree again.  I also changed focusoverlay to allow clicks  
>> through to an inputtext when the focus animation is happening.
>>
>>  This is just a first pass.  It doesn't reparent the input text
>>  sprite into the click tree, and it turns off the click tree when
>>  you mouse over in input element.  The test case works in Safari,
>>  and Firefox.  I have not tested IE.
>>
>>  LzSprite:  Move the canvas hiding from the CSS class style to the  
>> canvas
>>  div, so removing it just removes the div style (and the div
>>  reverts to the class style default).  Similarly for controlling
>>  visibility on all divs.  Correct fencepost error in __isMouseOver.
>>
>>  LzInputTextSprite:  Add documentation from Max.  Fix init clauses
>>  that were causing the schema-generator to warn.  Remove
>>  reparenting code, replace with hiding/showing the click tree.  Now
>>  we can just turn the whole click tree on and off, since we are not
>>  reparenting, which should be much more efficient.  Only re-enable
>>  click tree when we _actually_ leave the bounding box of the input
>>  element.
>>
>> Tests:
>>  Test case from LPP-8334
>>
>> Files:
>> M      WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js
>> M      WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js
>> M      WEB-INF/lps/lfc/kernel/dhtml/LzInputTextSprite.js
>> M      lps/components/lz/focusoverlay.lzx
>>
>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20090727-maxcarlson-U.tar
>