I'm saying we should try to use the standard DOM2 interface, and if that does 
not work for some browsers, it should be in a quirk.  It's my impression that 
the function calls are the standard, but maybe I am wrong.  My hope in using 
the standard is that any new browser (e.g., Chrome) will implement the 
standard, so is more likely to work out of the box.

On 2010-09-23, at 13:28, Henry Minsky wrote:

> Hmm, so you're saying we should use the stopPropagation() and
> preventDefault() (maybe) API and not use the properties below?
>                e.cancelBubble = true;
>                e.returnValue = false;
> 
> 
> 
> I agree with you that maybe we don't want to prevent the default behavior in
> some cases,
> maybe there could be an LFC API call, to toggle that behavior if we have
> control over it?
> 
> On Thu, Sep 23, 2010 at 1:23 PM, P T Withington <[email protected]> wrote:
> 
>> We do.  But just what Max said, we may have our logic wrong someplace.
>> 
>> This sample has a lot of crap in it that we do not need, because we only
>> support browsers with DOM level 2 and above (meaning their event system uses
>> addEventListener and stopPropagation and preventDefault are supported
>> API's).  We ought to stick with the DOM2 API's and not use the old DOM0
>> ones, even if they are supported for back-compatibility.
>> 
>> Something you have to be really careful about when you _do_ prevent the
>> default is whether you will be killing a default handler in the browser that
>> the user expects to work.  E.g., for touch events, we are very careful to
>> propagate and bubble gestures with more than one finger because those are
>> handled by the browser to implement pan/zoom.
>> 
>> So, here's a question:  If I am a power Opera user, I probably expect the
>> spacebar to act as a keyboard shortcut for scrolling.  Do we really want to
>> disable that in every OL app?  I don't think so.
>> 
>> On 2010-09-23, at 12:56, Henry Minsky wrote:
>> 
>>> I found some example code on the web, I'll see if we're doing something
>>> like this
>>> 
>>> function KillSpaceBar(e) {
>>>   var code;
>>>   e = e || window.event;
>>>   if (e.keyCode) {
>>>       code = e.keyCode;
>>>   } else if (e.which) {
>>>       code = e.which;
>>>   }
>>>   if (code == 32) {
>>>       e.cancelBubble = true;
>>>       e.returnValue = false;
>>> 
>>>       if (e.stopPropagation) {
>>>           e.stopPropagation();
>>>           e.preventDefault();
>>>       }
>>>       return false;
>>>   }
>>> }
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Sep 23, 2010 at 12:40 PM, Max Carlson <[email protected]>
>> wrote:
>>> 
>>>> This would be in the LzKeyboardKernel since it's a global handler.  I
>> would
>>>> guess we're not canceling bubbling on the event, or perhaps we need to
>>>> return false from the event handler?
>>>> 
>>>> 
>>>> On 9/23/10 9:25 AM, Henry Minsky wrote:
>>>> 
>>>>> There's an open bug regarding the space bar causing browser scrolling
>>>>> http://jira.openlaszlo.org/jira/browse/LPP-9381
>>>>> 
>>>>> 
>>>>>    OL 5.0.x - DHTML - Opera - Component Sample - When clicking space
>>>>>    key, the application will be scrolled
>>>>> 
>>>>> Do you happen to know where the code in the kernel is that's supposed
>> to
>>>>> be suppressing the space bar keyboard
>>>>> events from causing the browser to scroll? Safari and Opera both get
>> the
>>>>> whole browser window
>>>>> scrolled when you hit the space bar while focused on a checkbox or
>> other
>>>>> component.  Firefox seems to
>>>>> suppress the space bar scrolling behavior properly though.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> [email protected] <mailto:[email protected]>
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>> --
>>> Henry Minsky
>>> Software Architect
>>> [email protected]
>> 
>> 
> 
> 
> -- 
> Henry Minsky
> Software Architect
> [email protected]


Reply via email to