Hi...the failing tests, if they are Rhino related need to be ported over to Selenium. Rhino simply is not up to the task anymore.
Also we can revert the scripts back and make 4.0 with the old ones, And maybe make a later release with the new ones. I am open for that as well. Whatever you feel is better! Werner Am Di., 21. Feb. 2023 um 15:32 Uhr schrieb Paul Nicolucci < [email protected]>: > Hey Werner! Thanks! > > I hate to hijack this thread but wanted to make sure you were aware of the > issues we're facing with the TCK and the new JS. We have a thread started > yesterday: > https://markmail.org/message/ebpszw2hqyovp6ue#query:+page:1+mid:pvnqrp7oqkh24aud+state:results > > Regards, > > Paul Nicolucci > > On Tue, Feb 21, 2023 at 9:07 AM Thomas Andraschko < > [email protected]> wrote: > >> +1 yep, less and easier code is always worth refactoring >> >> Am Di., 21. Feb. 2023 um 15:00 Uhr schrieb Melloware < >> [email protected]>: >> >>> Less code is always better for me. :) even if there is no performance >>> gain. >>> >>> >>> On 2/21/2023 8:39 AM, Werner Punz wrote: >>> > Hi everyone, just a short update about my plans on our ajax codebase >>> > post 4.0.0. >>> > I have planned following and have opened a branch for the post 4.0 >>> > release on my github project. >>> > I have opened a feature branch, where I try new things out: >>> > >>> > https://github.com/werpu/jsfs_js_ts/tree/feature/new_things >>> > >>> > a) Given that the last remnants of IE11 now are phased out by >>> > Microsoft, I can drop another compatibility layer. >>> > >>> > The streams will be replaced with arrays internally the 2 missing >>> > methods can be shimmed in. >>> > This already is done on my feature branch and working. Saves >>> > 15-20kbyte of code on faces-development.js >>> > (in faces.js not so much 1-2kbyte). I was able to add the shims >>> > without altering the javascript array itself! >>> > I don´t expect a huge change in performance by moving from Streams to >>> > native api. >>> > >>> > The lazy streams had some advantages over array processing, but that >>> > is made up by native execution of parts of >>> > the code now. >>> > It is mostly to phase out another now mostly obsolete API! >>> > >>> > b) I was able to simplify the request queue controller. It now is as >>> > barebones as it can get: >>> > https://gist.github.com/werpu/54479ab8bff0f1c11bf67dc33fd663c5 >>> > >>> > Other plans, just mostly cleanup and fixes for bugs. The XhrRequest is >>> > the last component which could benefit from another round of cleanup! >>> > >>> > >>> > >>> > >>> >>
