Yes. This appears to be it. I did not step through the code, but re-adding in wrappedEvent.stopPropagation(); seems to resolve the issues I was seeing.
stopImmediatePropogation() probably does nothing at this point unless event listeners were added directly to HTML elements. Either way, my code changes in the browser-event branch dispatch MouseEvents and KeyboardEvents rather than BrowserEvents unless the goog BrowserEvent is some other type (such as TouchEvent). I’m ready to merging it in, but I’m going to wait until I get feedback on whether these changes are good or bad. One day it might not be a bad idea to patch (or rewrite) the goog Event code, but I have bigger fish to fry at this point. Thanks, Harbs > On Jul 20, 2017, at 3:30 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > I haven't had time to dig into it, but IIRC, because we are using Google > Closure Events, stopImmediatePropagation will have no effect on what event > listeners Google will call. If the underlying DOM event does support > stopImmediatePropagation then it will stop other listeners on that DOM > object, but Google's addEventListener calls have built their own database > of who to call. Did you step through the code after > stopImmediatePropagation to see if Google kept running the loop on the > listeners? > > Throwing an error in stopImmediatePropagation is definitely a hack and > probably only works if it is the last line of a handler, but I think at > the time I couldn't find another way. > > One way, would be to modify Google Closure Events and truly support > stopImmediatePropagation. I'm not convinced the other checkins I saw > would stop Google's code from calling additional listeners on the same > target. > > HTH, > -Alex > > On 7/19/17, 2:20 PM, "Harbs" <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>> wrote: > >> Yes. MDL does not seem to be a problem. >> >> I just committed some more changes which makes my changes seem to work, >> but I must be missing something. MouseEvents seem to work as well as >> BrowserEvents. With KeyboardEvents, I’m getting mixed results. For some >> reason, I seem to be losing focus more easily with the KeyboardEvent >> change than with BrowserEvents. >> >> I don’t know why. >> >> I’m going to leave the browser-event branch until I either figure it out >> or get some feedback on this… >> >>> On Jul 19, 2017, at 3:25 PM, piotrz <piotrzarzyck...@gmail.com> wrote: >>> >>> Yishay, Harbs, >>> >>> Are you using MDL in your project - does all events are working after >>> changes ? I mean click on controls like switch, new drop down list (you >>> can >>> check it in MDLExample app) >>> >>> Thanks, >>> Piotr >>> >>> >>> >>> ----- >>> Apache Flex PMC >>> piotrzarzyck...@gmail.com >>> -- >>> View this message in context: >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl >>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl> >>> ex-development.2333347.n4.nabble.com >>> <http://ex-development.2333347.n4.nabble.com/>%2FFlexJS-stopImmediatePropagation-tp >>> 63418p63423.html&data=02%7C01%7C%7C63e240772d4b4b37819908d4ceec0567%7Cfa7 >>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636360960489661258&sdata=otqYIABq >>> 5f8d4vz2ti393hVFtm7Ao3NzM0gabMJKh6w%3D&reserved=0 >>> Sent from the Apache Flex Development mailing list archive at >>> Nabble.com <http://nabble.com/>.
