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]
