There's also a 3rd course we can take in browsers that support DOM2
events (not sure IE7 does). You can listen for the event in the
'capture' phase, which means you grab it before _any_ DOM element gets
it. If you 'capture' an event like this, there is no bubbling or
default. Then you can dispatch the event (or some synthesized event)
to a particular DOM element as necessary.
I don't think we pursued this initially because IE did not support
DOM2 events. Maybe IE7+ does...
On 2009-07-06, at 10:50EDT, Henry Minsky wrote:
Ooh, I think you've isolated the problem -- it is only the 'cancel
default
behavior' part that is
causing text selection and links to stop working in IE7 and Safari.
Cancelling bubbling is independent of this
issue.
On Sat, Jul 4, 2009 at 4:07 PM, P T Withington <[email protected]> wrote:
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]
--
Henry Minsky
Software Architect
[email protected]
