So ... does anyone remember what the __cancelKeys flag is supposed to be doing for us? Is this block of code now obsoleted by the call to updateControlKeys?
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]
