I just created a branch with some of these ideas.
> On Jul 19, 2017, at 12:14 PM, Harbs <harbs.li...@gmail.com> 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 stopImmediatePropagation by throwing an error.
> (See org.apache.flex.events.Event for details.)
>
> I’m not sure I understand all the issues involved. It seems like a goog issue
> if I understand it correctly, and I’m guessing it has to do with supporting
> browsers prior to IE 9. (Event.stopImmediatePropagation() is only supported
> in the browser from IE 9 and later.)[1]
>
> My current issue is that I’m using a custom KeyboardEvent for editing in TLF.
> This event does not bubble and there’s no reason for
> stopImmediatePropagation(). In fact there’s not even a target for my event
> because I’m not even dispatching it. I’m feeding the event directly into the
> handler functions.
>
> Throwing an error unnecessarily seems messy, and I have some code which is
> supposed to run after the event is handled. I guess I can wrap it in a
> try/catch/throw, but that also seems messy.
>
> The main ideas I have are:
>
> 1. Subclass KeyboardEvent for my custom event and override
> stopImmediatePropagation() and just swallow the call. It’ll solve my specific
> issue, but doesn’t deal with the underlying problem.
> 2. Change the code in org.apache.flex.events.Event to only throw the error if
> there’s a target. That feels like “just in case” code.
> 3. Try and deal with the need to throw stopImmediatePropagation. That seems
> hard, but if it’s doable, it seems worth-while.
>
> To see if tackling #3 is doable, I looked at the use of
> stopImmediatePropagation in the Framework code. I discounted any use of
> stopImmediatePropagation which is in a COMPILE::SWF block, because that’s not
> a problem. Here’s what I found:
>
> Almost every case is either a MouseEvent of a KeyboardEvent.
>
> The only exceptions that I saw were:
> DateFieldMouseController.changeHandler
> EditableTextKeyboardController.inputChangeHandler
> DispatchTLFKeyboardEventBead.focusEventHandler
>
> Now, what’s weird about MouseEvents and KeyboardEvents is that they’re not
> really dispatched when you attach eventListeners on interactive objects.
> Instead we get BrowserEvents.
> org.apache.flex.core.HTMLElementWrapper.fireListenerOverride intercepts the
> goog fireListener call and wraps the goog BrowserEvent in a Flex one.
>
> As an aside, I wonder if it should be wrapped in either a MouseEvent or
> KeyboardEvent depending on the underlying event object type. (That can be
> done by checking eventObject.event_.constructor.name.)
>
> Back to the issue at hand, BrowserEvent has the following code:
> public function stopImmediatePropagation():void
> {
> //wrappedEvent.stopImmediatePropagation(); // not in
> goog.events.BrowserEvent
> wrappedEvent.stopPropagation();
> }
>
> While the comment is true, wrappedEvent.event_ *does* have
> stopImmediatePropagation in every browser from IE 9 and later.
>
> So, for KeyboardEvents and MouseEvents (which are really BrowserEvents), it
> seems to me that referencing the wrappedEvent.event_ is a good solution. If
> we actually dispatch MouseEvents and KeyboardEvents instead of BrowserEvents,
> the same can be done to those.
>
> For other event types, I’m not actually sure what stopImmediatePropagation
> needs to do and what would happen if the error is not thrown.
>
> If you’re still reading, thanks for bearing with me… :-)
>
> Thoughts? Comments? Corrections?
>
> Harbs
>
> [1]https://developer.mozilla.org/en-US/docs/Web/API/Event/stopImmediatePropagation
>
> <https://developer.mozilla.org/en-US/docs/Web/API/Event/stopImmediatePropagation>
