Re: [FlexJS] stopImmediatePropagation

7 2:55:10 PM To: dev@flex.apache.org Subject: Re: [FlexJS] stopImmediatePropagation Good. I confirmed that this survives minification. > On Jul 24, 2017, at 12:41 AM, Harbs wrote: > > Oh.It seems like there’s an official way to do this: > BrowserEvent.prototpye.getBrowserEvent() &g

Re: [FlexJS] stopImmediatePropagation

Hi Harbs, I will check your changes later today or tomorrow evening. Thank you, Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63501.html Sent from the Apache

Re: [FlexJS] stopImmediatePropagation

Good. I confirmed that this survives minification. > On Jul 24, 2017, at 12:41 AM, Harbs wrote: > > Oh.It seems like there’s an official way to do this: > BrowserEvent.prototpye.getBrowserEvent() > >> On Jul 24, 2017, at 12:34 AM, Harbs > > wrote: >> >> Bah! >> >

Re: [FlexJS] stopImmediatePropagation

Oh.It seems like there’s an official way to do this: BrowserEvent.prototpye.getBrowserEvent() > On Jul 24, 2017, at 12:34 AM, Harbs wrote: > > Bah! > > I just discovered another issue with this branch. > > The goog.BrowserEvent “event_” property is renamed when the code is minified. > Without

Re: [FlexJS] stopImmediatePropagation

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 wrote: > > I feel like I went down the rabbit hole wi

Re: [FlexJS] stopImmediatePropagation

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. myB

Re: [FlexJS] stopImmediatePropagation

Yes. That seems to be the case: https://github.com/google/closure-library/blob/608e0eaaa42bb5f041a7f067f254907d47edf7d1/closure/goog/events/eventtarget.js#L371 > On J

Re: [FlexJS] stopImmediatePropagation

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" wrote: >Yes. I need to copy the code from BrowserEvent. > >Interestingly, goog.Events does not distinguish between target and >currentTarget. That d

Re: [FlexJS] stopImmediatePropagation

mail.com > -- > View this message in context: > http://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63479.html > Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

Ahh Sorry I missed the point in his post. Do you see some solution ? Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63479.html Sent from the Apache Flex

Re: [FlexJS] stopImmediatePropagation

rk. I will > check whether with MDLExample is happening same, cause building locally I > don't have tabs at all! > > Thanks, Piotr > > > > - > Apache Flex PMC > piotrzarzyck...@gmail.com > -- > View this message in context: > http://apache-flex-de

Re: [FlexJS] stopImmediatePropagation

.@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63476.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

Yes. It looks like I missed that. > On Jul 20, 2017, at 10:59 AM, Alex Harui wrote: > > I think the FlexJS browser event has logic that, when you access the > target, it checks for a flexjs_wrapper property. I would expect problems > if MouseEvent and KeyboardEvent don't have the same way of fi

Re: [FlexJS] stopImmediatePropagation

I think the FlexJS browser event has logic that, when you access the target, it checks for a flexjs_wrapper property. I would expect problems if MouseEvent and KeyboardEvent don't have the same way of finding the element wrapper. -Alex On 7/20/17, 12:15 AM, "Harbs" wrote: >Yes. This appears to

Re: [FlexJS] stopImmediatePropagation

? > > Thanks, Piotr > > > > - > Apache Flex PMC > piotrzarzyck...@gmail.com > -- > View this message in context: > http://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63442.html > Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63442.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

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

Re: [FlexJS] stopImmediatePropagation

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, bu

Re: [FlexJS] stopImmediatePropagation

context: > http://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63423.html > Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

://apache-flex-development.247.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63423.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

ve the > issue we're facing, so I'd vote yes. > > I'm not sure what the purpose of throwing the error was in the first place, > as EventDispatcher catches and ignores it anyway. > > > > -- > View this message in context: > http://apache-flex-develo

Re: [FlexJS] stopImmediatePropagation

http://apache-flex-development.2333347.n4.nabble.com/FlexJS-stopImmediatePropagation-tp63418p63421.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] stopImmediatePropagation

I just created a branch with some of these ideas. > On Jul 19, 2017, at 12:14 PM, Harbs wrote: > > This is kind of long, so please bear with me… ;-) > > I’m not sure what the “right” way to deal with my issue is, so I’m looking > for input. > > Currently, FlexJS deals with stopImmediatePropag

[FlexJS] stopImmediatePropagation

This is kind of long, so please bear with me… ;-) I’m not sure what the “right” way to deal with my issue is, so I’m looking for input. Currently, FlexJS deals with stopImmediatePropagation by throwing an error. (See org.apache.flex.events.Event for details.) I’m not sure I understand all the

Re: FlexJS stopImmediatePropagation

That’s fine. We’re long overdue on a release. I would like to merge it into develop as soon as we cut the release branch though. On Aug 9, 2016, at 7:28 PM, Alex Harui wrote: >>> >>> I’d like to get to the point where we can merge the sprite-refactor >>> branch back into develop before we sta

RE: FlexJS stopImmediatePropagation

osoft.com/en-us/WindowsForBusiness/End-of-IE-support -Mark -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Tuesday, August 09, 2016 12:22 PM To: dev@flex.apache.org Subject: [Non-DoD Source] Re: FlexJS stopImmediatePropagation Historically, market share reports like this have no

Re: FlexJS stopImmediatePropagation

On 8/9/16, 8:59 AM, "Harbs" wrote: >BTW: > >If we look at getting rid of goog.events, we might want to look at >getting rid of goog.inherits and goog.base as well. IMO, goog.events is separate from goog.inherits and goog.base. Erik would know best, but I think the GCC optimizer understands go

Re: FlexJS stopImmediatePropagation

Historically, market share reports like this have not been accurate for large enterprises and schools which often standardize on something one or two versions back. So, I tend to be conservative about what versions we need to support. -Alex On 8/9/16, 9:16 AM, "Kessler CTR Mark J" wrote: >Just

RE: FlexJS stopImmediatePropagation

Just a thought, I think at this point if we are still worrying about IE we should only worry about IE11[2] since even IE9 [1] is in heavy decline. [1] https://www.netmarketshare.com/report.aspx?qprid=3&qpaf=&qpcustom=Microsoft+Internet+Explorer+9.0&qpcustomb=0 [2] https://www.netmarketshare.co

Re: FlexJS stopImmediatePropagation

BTW: If we look at getting rid of goog.events, we might want to look at getting rid of goog.inherits and goog.base as well. For IE9+, I think we can use Object.create() instead.[1] [1]https://developer.mozilla.org/en/docs/Web/JavaScript/Inheritance_and_the_prototype_chain On Aug 9, 2016, at 6:

Re: FlexJS stopImmediatePropagation

You do get an error, but the error loses the stack. All you have is the function which threw the event, but you have no trace of the object which handled the event (and caused the error). I have no idea why this is so. I assume it has to do with “callback hell” and the callbacks which the event

Re: FlexJS stopImmediatePropagation

On 8/9/16, 3:15 AM, "Harbs" wrote: >The way stopImmediatePropagation is being handled in FlexJS is like this: > > try { >return org.apache.flex.events.EventDispatcher.base(this, >'dispatchEvent', event); > } catch (e) { >if (e.name != "stopImmediatePropagation") > throw e; > } >

FlexJS stopImmediatePropagation

The way stopImmediatePropagation is being handled in FlexJS is like this: try { return org.apache.flex.events.EventDispatcher.base(this, 'dispatchEvent', event); } catch (e) { if (e.name != "stopImmediatePropagation") throw e; } This is proving to be very painful because almo