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]
