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

[Raju Bitter]

Yes, I can only agree with what you are saying about the SWF click  
mode. I found that a strange behavior since I've been using the 2.1  
version of OL.

On Jul 28, 2009, at 4:50 PM, P T Withington wrote:

> 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
>>
>