AIUI, for bubbling to work automatically, setParentEventTarget needs to be called to construct the hierarchy.
Maybe we should have a bead that takes care of this (on addedToParent or something) for applications which rely on bubbling for non-browser-native events. There is a dispatchBubblingEvent in HTMLElementWrapper which forces the event to bubble up for all events, but it’s JS only. We could add a method for SWF for compatibility. I just tested dispatchBubblingEvent and that makes the alert appear. None of this explains why it worked before my change, though... > On Dec 23, 2019, at 10:17 PM, Greg Dove <[email protected]> wrote: > > Harbs, I can only check Crux in 4-5 days time. > From memory I did set up something specific to make either capture or > bubbling work, maybe that was for the 'addedToStage' event emulation. I > think one of them (either capture or bubbling) was not working by default, > or did was not easy to enable by default. > > > > On Tue, Dec 24, 2019 at 9:13 AM Harbs <[email protected]> wrote: > >> Nope. Didn’t figure it out. >> >> It looks like Crux listens on the ancestor and is relying on bubbling. >> >> I’m guessing bubbling is not working, but I have no idea why that would >> have changed with my commit. >> >>> On Dec 23, 2019, at 10:06 PM, Piotr Zarzycki <[email protected]> >> wrote: >>> >>> Harbs, >>> >>> I feel like Carlos has started his Christmas time ;) I'm glad that you >>> figured it out! :) >>> >>> pon., 23 gru 2019 o 21:01 Harbs <[email protected] <mailto: >> [email protected]>> napisał(a): >>> >>>> The asconfig file did not include the necessary metadata. Fixed that… >>>> >>>> OK. I’m not getting any errors, but UserForm is dispatching an event not >>>> listened to by anyone. >>>> >>>> Where is the listener supposed to be attached? Maybe it’s listening to >> the >>>> wrong object? >>>> >>>> >>>>> On Dec 23, 2019, at 9:35 PM, Harbs <[email protected]> wrote: >>>>> >>>>> I’m getting an error that UserForm.user is null. >>>>> >>>>> I have no idea where that should have been set, and I have no idea how >>>> my commit could have possibly effected that. I don’t see anything that >>>> would initialize the user variable. >>>>> >>>>> If you want my help on this, I’m going to need some direction. >>>>> >>>>> Thanks, >>>>> Harbs >>>>> >>>>>> On Dec 23, 2019, at 9:28 PM, Harbs <[email protected] <mailto: >> [email protected]> <mailto: >>>> [email protected] <mailto:[email protected]>>> wrote: >>>>>> >>>>>> I fixed this, but I have no idea what Crux is supposed to do. >>>>>> >>>>>> What am I looking for? >>>>>> >>>>>>> On Dec 23, 2019, at 8:30 PM, Harbs <[email protected] <mailto: >> [email protected]> <mailto: >>>> [email protected] <mailto:[email protected]>>> wrote: >>>>>>> >>>>>>> I can’t compile Jewel right now. >>>>>>> >>>>>>> I’m getting an error: >>>>>>> >>>>>>> [java] >>>> >> /Apache/royale-asjs/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/IconButton.as(104): >>>> col: 13 Access of possibly undefined property classSelectorList. >>>>>>> [java] >>>>>>> [java] classSelectorList.toggle("icon", (_icon != >>>> null)); >>>>>>> [java] ^ >>>>>>> >>>>>>> >>>>>>>> On Dec 23, 2019, at 7:17 PM, Carlos Rovira <[email protected] >> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> >> wrote: >>>>>>>> >>>>>>>> Compilation is ok. The problem is that example is not really >> working. >>>>>>>> In that example you should be able to fill the form and push the >>>> button. >>>>>>>> After that a JS Alert should be show with the ID of the user record >>>> saved. >>>>>>>> That Alert is not show anymore. >>>>>>>> If you revert locally that commit and recompile Core and then the >>>> example >>>>>>>> and run you'll be able to see it again. >>>>>>>> We have a client complaining about the app stopped to work today >>>> since they >>>>>>>> are using Crux. >>>>>>>> After investigation I was able to trace the problem to that commit. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Carlos >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> El lun., 23 dic. 2019 a las 17:59, Harbs (<[email protected] >> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>) >> escribió: >>>>>>>> >>>>>>>>> I compiled CruxQuickStartBasic and I don’t see anything wrong. >>>>>>>>> >>>>>>>>> Can you give me more clues? >>>>>>>>> >>>>>>>>> FWIW, I used Ant, is the problem specific to Maven? >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Dec 23, 2019, at 6:26 PM, Carlos Rovira < >> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Harbs, >>>>>>>>>> >>>>>>>>>> seems recent changes break Crux library >>>>>>>>>> (commit: f50c9990a3190cf681364905525656984ab2e9c5 - Cleaned up >>>>>>>>>> ElementWrapper and HTMLElementWrapper) >>>>>>>>>> I'm trying to see what could be the problem. I suppose that is the >>>> change >>>>>>>>>> of HTMLElementWrapper now extending ElementWrapper. >>>>>>>>>> Tried to change one for the other in Crux library, but with no >> luck >>>>>>>>>> I'm using /examples/crux/CruxQuickStartBasic to test >>>>>>>>>> Can you see what could be wrong? >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Carlos >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> El dom., 22 dic. 2019 a las 17:24, Harbs (<[email protected] >> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>) >>>>>>>>> escribió: >>>>>>>>>> >>>>>>>>>>>> There is lots of what looks like shared code, so could >>>>>>>>>>> HTMLElementWrapper extend ElementWrapper? >>>>>>>>>>> >>>>>>>>>>> Totally. Excellent idea. >>>>>>>>>>> >>>>>>>>>>>> On Dec 22, 2019, at 5:46 PM, Alex Harui >> <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> In a quick look at history, HTMLElementWrapper's override logic >>>> was the >>>>>>>>>>> same as ElementWrapper's. >>>>>>>>>>>> >>>>>>>>>>>> Maybe as you upgraded HTMLElementWrapper's logic, ElementWrapper >>>> should >>>>>>>>>>> have changed as well but didn't? >>>>>>>>>>>> >>>>>>>>>>>> There is lots of what looks like shared code, so could >>>>>>>>>>> HTMLElementWrapper extend ElementWrapper? >>>>>>>>>>>> >>>>>>>>>>>> My 2 cents, >>>>>>>>>>>> -Alex >>>>>>>>>>>> >>>>>>>>>>>> On 12/22/19, 1:00 AM, "Harbs" <[email protected] <mailto: >> [email protected]> <mailto: >>>> [email protected] <mailto:[email protected]>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> We found a weird bug with events and currentTarget. >>>>>>>>>>>> >>>>>>>>>>>> I traced the problem to the following: >>>>>>>>>>>> >>>>>>>>>>>> The app loads both HTMLElementWrapper and ElementWrapper. The >>>> lstener >>>>>>>>>>> overrides in the two are stepping on each other. Here’s what >>>> happens: >>>>>>>>>>>> >>>>>>>>>>>> 1. HTMLElementWrapper is loaded first. It replaces >>>>>>>>>>> goog.events.fireListener with its fireListenerOverride function >>>> (which >>>>>>>>>>> calls the existing one when it’s done). >>>>>>>>>>>> 2. ElementWrapper is loaded next and it replaces the existing >>>>>>>>>>> goog.events.fireListener function — which was already changed to >>>> point >>>>>>>>> to >>>>>>>>>>> HTMLElementWrapper.fireListenerOverride with the one from >>>>>>>>> ElementWrapper. >>>>>>>>>>>> 3. When an event is actually dispatched, >>>>>>>>>>> ElementWrapper.fireListenerOverride first changes the event to a >>>> royale >>>>>>>>>>> BrowserEvent instead of a goog one. >>>>>>>>> HTMLElementWrapper.fireListenerOverride >>>>>>>>>>> is then called and where it expects a goog BrowserEvent, it in >> fact >>>>>>>>> gets a >>>>>>>>>>> royale BrowserEvent. This causes the wrappedEvent to be the wrong >>>> type >>>>>>>>> and >>>>>>>>>>> messes things up down the line. >>>>>>>>>>>> >>>>>>>>>>>> I’m not sure of the best way to fix this. >>>>>>>>>>>> >>>>>>>>>>>> * We could check the event type in >>>> HTMLElementWrapper/ElementWrapper, >>>>>>>>>>> but that’s just-in-case code. >>>>>>>>>>>> * I’m not completely sure why we need this logic in both >>>>>>>>>>> ElementWrapper and HTMLElementWrapper. Is there something that >> can >>>> be >>>>>>>>>>> changed there? >>>>>>>>>>>> * Maybe there’s some way for ElementWrapper to know that some >>>> other >>>>>>>>>>> class is installing an override? >>>>>>>>>>>> >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> Harbs >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Carlos Rovira >>>>>>>>>> http://about.me/carlosrovira <http://about.me/carlosrovira> < >> http://about.me/carlosrovira <http://about.me/carlosrovira>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Carlos Rovira >>>>>>>> http://about.me/carlosrovira <http://about.me/carlosrovira> < >> http://about.me/carlosrovira <http://about.me/carlosrovira>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> -- >>> >>> Piotr Zarzycki >>> >>> Patreon: *https://www.patreon.com/piotrzarzycki < >> https://www.patreon.com/piotrzarzycki> >>> <https://www.patreon.com/piotrzarzycki < >> https://www.patreon.com/piotrzarzycki>>* >> >>
