You need to separate out the concepts:
1) cancel bubbling: means the event will not 'bubble' to outer DOM
elements. It starts on the innermost one, and moves to enclosing ones
until it is either cancelled or reaches the root.
2) suppress default: means that the browser default action will not
be taken (for each DOM element the event bubbles to).
If we have _fully_ handled an event in the LFC (e.g., intercept a
keystroke and trigger a command), we would do both. But in some
cases, we might want to either allow bubbling or allow the default
browser action. E.g., if we need to permit the user to use click-drag
to select text on the underlying element, we need to let the default
action happen. I think our separation of the two possibilities and
decision when to invoke one or the other or both has been haphazard to
date. We need to organize it better.
On 2009-07-03, at 15:30EDT, Henry Minsky wrote:
> So, I think I sort of remember that it was necessary to cancel the
> mouse
> events because if we didn't, then a copy of the mouse click event
> would get
> sent someplace up the hierarchy that we didn't want it to go, but I
> forget
> what the test case was. Does this ring a bell with anyone? Was the
> click
> getting passed up the DOM hierarchy in some way that caused behavior
> to be
> different than SWF or something?
>
> I don't *think* that this issue had anything to do with the
> embedding of an
> iframe in HTML (which is what the current bug I'm working on ,
> LPP-8303 and
> LPP-8306), I think it was some bug in
> basic nesting of views, but I cannot remember it now. Must search
> email...
>
>
>
>
> On Tue, Jun 30, 2009 at 10:45 PM, Henry Minsky <hminsky at laszlosystems.com
> >wrote:
>
>> 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 <ptw at pobox.com>
>> 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 <hminsky at laszlosystems.com
>>>>> 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 <ptw at pobox.com>
>>>>> 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 <ptw at pobox.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 2009-06-30, at 15:20EDT, Henry Minsky wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I isolated the bug in http://openlaszlo.org/jira/browse/LPP-8303down
>>>>>>>> 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
>>>>>>> hminsky at laszlosystems.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> hminsky at laszlosystems.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky at laszlosystems.com
>>>>
>>>
>>>
>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
>>
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com