Yeah, I need to isolate out the code path that lz.embed.attachEventHandler is taking, and see if I can reproduce this behavior in a small test.
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-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] >> > > -- Henry Minsky Software Architect [email protected]
