Iirc it was dispatching capture phase events that was 'difficult'. I think I had to override something and undo something in Royale that was switching off goog support for that. It was only needed in the JSStageEvents emulation stuff iirc. I have no idea what the issue is, but that is probably what I would look at first. Have to go now... I can look at this if needed but not for a few days.
On Tue, 24 Dec 2019, 09:38 Harbs, <[email protected]> wrote: > 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>>* > >> > >> > >
