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 <[email protected]
>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 <[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-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
[email protected]
--
Henry Minsky
Software Architect
[email protected]
--
Henry Minsky
Software Architect
[email protected]
--
Henry Minsky
Software Architect
[email protected]
--
Henry Minsky
Software Architect
[email protected]
