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]
