Bah! I just discovered another issue with this branch.
The goog.BrowserEvent “event_” property is renamed when the code is minified. Without hacking the goog code, using that property is not gonna work… > On Jul 23, 2017, at 1:44 PM, Harbs <harbs.li...@gmail.com> wrote: > > I feel like I went down the rabbit hole with this… > > I think MouseEvent needs to work much like BrowserEvent in that it proxies to > the underlying event to get properties, coordinates, etc. > > What I’m not really sure about is what happens if you want to dispatch a > MouseEvent on an element? (i.e. myButton.dispatchEvent(new > MouseEvent(MouseEvent.CLICK))) > > Is that something which currently works? How should it work? Should localX > and localY be user-settable? > > There’s also some code in MosueEvent in getScreenX and getScreenY which > calculates _stagePoint using localToGlobal. I’m not sure that makes sense > either. Assuming we can rely on the native event, there’s no need to do those > calculations ourselves. I can not find a single use of MouseEvent anywhere, > so I don’t have any way of confirming that this ever worked or did anything. > Was it ever used in any of the examples? > > >> On Jul 21, 2017, at 6:06 PM, Harbs <harbs.li...@gmail.com >> <mailto:harbs.li...@gmail.com>> wrote: >> >> Yes. That seems to be the case: >> https://github.com/google/closure-library/blob/608e0eaaa42bb5f041a7f067f254907d47edf7d1/closure/goog/events/eventtarget.js#L371 >> >> <https://github.com/google/closure-library/blob/608e0eaaa42bb5f041a7f067f254907d47edf7d1/closure/goog/events/eventtarget.js#L371> >> >>> On Jul 21, 2017, at 5:18 PM, Alex Harui <aha...@adobe.com.INVALID >>> <mailto:aha...@adobe.com.INVALID>> wrote: >>> >>> I think other goog code updates currentTarget as needed. They are the >>> same when no capture or bubbling, IIRC. >>> >>> -Alex >>> >>> On 7/20/17, 11:52 PM, "Harbs" <harbs.li...@gmail.com >>> <mailto:harbs.li...@gmail.com>> wrote: >>> >>>> Yes. I need to copy the code from BrowserEvent. >>>> >>>> Interestingly, goog.Events does not distinguish between target and >>>> currentTarget. That does not seem very useful: >>>> >>>> * Target of the event. >>>> * @type {Object|undefined} >>>> */ >>>> this.target = opt_target; >>>> >>>> /** >>>> * Object that had the listener attached. >>>> * @type {Object|undefined} >>>> */ >>>> this.currentTarget = this.target; >>>> >>>>> On Jul 21, 2017, at 9:21 AM, piotrz <piotrzarzyck...@gmail.com >>>>> <mailto:piotrzarzyck...@gmail.com>> wrote: >>>>> >>>>> Ahh Sorry I missed the point in his post. Do you see some solution ? >>>>> >>>>> Piotr >>>>> >>>>> >>>>> >>>>> ----- >>>>> Apache Flex PMC >>>>> piotrzarzyck...@gmail.com <mailto: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%2FFlexJS-stopImmediatePropagation-tp >>>>> 63418p63479.html&data=02%7C01%7C%7C33b41ee272044f297c9208d4d005185f%7Cfa7 >>>>> b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636362167683568915&sdata=xo66CMSg >>>>> ME%2BdFt7dg5qU6%2BYv7quJw6REm%2B5mKJbwpS0%3D&reserved=0 >>>>> Sent from the Apache Flex Development mailing list archive at >>>>> Nabble.com. >>>> >>> >> >
