Hmm, there's this code in LzSprite which does muck with the event, it even
has a warning from andre...

            // FIXME: [20090602 anba] this prevents text selection, see
LPP-8200
            if (LzKeyboardKernel.__cancelKeys && e.keyCode == 0) {
                e.cancelBubble = true;
                e.returnValue = false;
            }



On Tue, Jun 30, 2009 at 8:41 PM, P T Withington <[email protected]> wrote:

> We must be doing something more than just attaching the handler.  We must
> be somehow stifling the event.  Normally events go to the inner-most DOM
> element first.  The only way I can think that the iframe could prevent an
> inner element from getting onclick is if it registers for the 'capture'
> phase (which means it has to pass 'true', I think as the last arg to
> attachEventHandler?  That's the only way an outer element can get hold of an
> event before an inner one.
>
>
> On 2009-06-30, at 19:27EDT, Henry Minsky wrote:
>
>  well, a simple test case doesn't show the bug, I can attach an onclick
>> handler onto
>> the main document of an iframe, and I can attach an onclick handler onto a
>> span of text
>> in the iframe, and clicking fires both handlers.
>>
>> So I guess I need to make a more detailed model of what we're doing with
>> the
>> event
>> handler attacher in lz.embed.
>>
>>
>> On Tue, Jun 30, 2009 at 6:52 PM, Henry Minsky <[email protected]
>> >wrote:
>>
>>  Well, we're installing the event handlers for mousedown and click onto
>>> the
>>> actual iframe element in the DHTML app, so maybe that just stops the
>>> event
>>> from propagating into the iframe, in Safari and IE7. I'll set up a simple
>>> test case to see if that is the case. Maybe the whole 'capture/bubble'
>>> model
>>> gets broken if it crosses an iframe boundary in the browser.
>>>
>>>
>>>
>>>
>>> On Tue, Jun 30, 2009 at 4:27 PM, P T Withington <[email protected]> wrote:
>>>
>>>  Well something is weird because normally _adding_ a handler to mouse
>>>> click
>>>> does not cancel/intercept the event.  If you just add a handler and
>>>> don't
>>>> call suppressDefault or cancelBubble, then the event should be seen by
>>>> all
>>>> the listeners (and by the browser default action).
>>>>
>>>> I know you were working in this area recently with respect to the
>>>> keyboard
>>>> update method that tries to pick off the shift keys from the mouse
>>>> event.
>>>> Maybe something went awry there?  Or maybe the way the iframe manager is
>>>> registering to listen to mouse events it screwing things up.
>>>>
>>>> If you listen in the 'capture' phase (i.e., grab the event before it is
>>>> sent to any DOM elements, you can intercept the event; but I did not
>>>> think
>>>> we did that.
>>>>
>>>>
>>>> On 2009-06-30, at 16:00EDT, Henry Minsky wrote:
>>>>
>>>> The text selection getting nuked is a bug in safari. The inability to
>>>>
>>>>> click
>>>>> on a <a> link happens
>>>>> in both safari and IE7 (it is due to the intercept of the 'click'
>>>>> event)
>>>>>
>>>>> On Tue, Jun 30, 2009 at 3:58 PM, P T Withington <[email protected]> wrote:
>>>>>
>>>>> On 2009-06-30, at 15:20EDT, Henry Minsky wrote:
>>>>>
>>>>>>
>>>>>> I isolated the bug in http://openlaszlo.org/jira/browse/LPP-8303 down
>>>>>> to
>>>>>>
>>>>>>  this code in iframemanager.js
>>>>>>>
>>>>>>> in __setSendMouseEvents , the iframemanager binds the 'mousedown' and
>>>>>>> 'click' events
>>>>>>>
>>>>>>>           lz.embed.attachEventHandler(iframe.document, 'mousedown',
>>>>>>> lz.embed.iframemanager, '__mouseEvent', id);
>>>>>>>
>>>>>>>           lz.embed.attachEventHandler(iframe.document, 'click',
>>>>>>> lz.embed.iframemanager, '__mouseEvent', id);
>>>>>>>
>>>>>>> And those cause Safari to no longer be able to drag-select text or to
>>>>>>> click
>>>>>>> on links.
>>>>>>>
>>>>>>> Is there some way we can re-send those events back to the browser, if
>>>>>>> thise
>>>>>>> code is  intercepting them?
>>>>>>>
>>>>>>>
>>>>>>>  These events all bubble, but are also all cancellable.  Is the event
>>>>>> handler cancelling them or suppressing the default action?
>>>>>>
>>>>>> We're not grabbing these events in capture phase (before any DOM
>>>>>> element
>>>>>> gets to see them) are we?
>>>>>>
>>>>>> Is this _only_ a bug in Safari?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> [email protected]
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> [email protected]
>>>
>>>
>>>
>>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> [email protected]
>>
>
>


-- 
Henry Minsky
Software Architect
[email protected]

Reply via email to