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>
