Datepicker does not close

Datepicker does not close

rf1234rf1234 Posts: 915Questions: 46Answers: 127

Hi, I am using the latest Editor version. When using more complex Editor pop ups with many fields and dependencies I get the problem that the date picker doesn't close after selecting a date. It just stays open, if I move the mouse away from the picker it might close after more than 10 seconds. The only way to close it is to hit the tab key.

Would you have an idea how to fix this? How can I force date picker to close when selecting a new date?

Answers

  • colincolin Posts: 6,205Questions: 0Answers: 1,066
    Answer ✓

    Hi @rf1243 ,

    We've not seen that problem - are you able to link to an example that demonstrates it please.

    Cheers,

    Colin

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    I will need to set this up for you. Where should I send the credentials for log in etc.? Can't post them here.

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    ok, will send it in a private message. Probably on Thursday this week.

  • allanallan Posts: 50,505Questions: 1Answers: 7,508 Site admin
    Answer ✓

    Send it on to me as a PM please. We are about to do a 1.9.1 release of Editor which changes datetime a little, so it might be worth trying that when its available.

    Allan

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    ok, that was overlapping :smile: Will try 1.9.1 asap.

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127
    edited October 2

    @allan
    I upgraded to the latest data tables release and to Editor 1.9.1. There was no change. I sent you my credentials etc in a private message.
    Roland

  • allanallan Posts: 50,505Questions: 1Answers: 7,508 Site admin
    Answer ✓

    Thank you for the link. I see the issue on your page - it looks like the click event is being cancelled by something before it can bubble up to the body element and close the input element.

    This is the code that Editor uses:

                $('body').on( 'click.'+namespace, function (e) {
                    var parents = $(e.target).parents();
    
                    if ( ! parents.filter( that.dom.container ).length && e.target !== that.dom.input[0] ) {
                        that._hide();
                    }
                } );
    

    The only way I was able to reproduce the error locally was to use:

    $('*').on('click', function (e) {
       return false;
    });
    

    to prevent the click event bubbling up.

    I'd suggest starting by looking for click event handlers with return false, or use stopPropagation() to stop bubbling.

    Allan

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    Thanks Allan. Will try a few things and get back to you!
    Roland

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    @allan
    I tried many things but nothing worked. Even deleting all the "preventDefaults()" etc. didn't work.
    I also noticed that the Editor code that should hide the widget when scrolling doesn't work for me either ... Any ideas?

    In this screenshot I marked everything that doesn't work for me.
    The only "hide()" that works is the one on "keydown" ...

  • allanallan Posts: 50,505Questions: 1Answers: 7,508 Site admin
    Answer ✓

    Its not working because there is something else on the page that it stopping the code for getting that far.

    I haven't dug into the code external to Editor, but those events just aren't happening (or rather that are being cut off).

    The way I'd approach debugging that myself is to start removing other plug-ins / libraries / event handlers on the page to see what is causing the issue.

    Alternatively start from a simple Editor example (since you can see it working on our example pages) and add the other plug-ins / libraries / event handlers you are using to, again, see which one is stopping the event from bubbling.

    Allan

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127
    edited October 4

    Sounds really, really cumbersome. My page has become so complex that I'll probably do nothing (and ask the users to use the tab key if the widget doesn't close) or I'll make my own field type that shows the day of week right next to the date and has no widget.

    I noticed that most of my users will type in the dates anyway and not select them with the widget (and that is facilitated with date masking so they only need to type 19102019 instead of 19/10/2019 or 19.10.2019). What most people want to know is the day of week of the entered date to figure out whether they have accidentally picked a week end.

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    @allan, I removed all of the code relevant for the new product one by one and tested it. No effect. The problem persisted. I was surprised. The problem only occurs when selecting the product "current account". All other products available on the same page work without issues.

    I also noticed further Javascript problems when working with "current account":
    - My tooltips in the Editor popup do not work any longer
    - after making a change the selection of the respective contract and the hiding of the unselected contracts does not work any longer.

    I will now remove all of the new code at once and then redo all of the 24 changes for the product one by one. Hopefully this will help.

    Is there any faster way?

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    I removed all of the new Javascript code for the product: NOTHING improved. I am getting a little desparate with this stuff now. What could I do?

  • allanallan Posts: 50,505Questions: 1Answers: 7,508 Site admin
    edited October 10

    Sorry for the delay in getting back to you - I've been off for a few days.

    Looking in more detail I think I was wrong about the stopPropagation - apologies. The effect did look like that, but actually I think what is happening is that you've got an infinite loop on the page which is making the page run very slow and really hard to debug.

    Specifically you have:

                .dependent('fixed.first_repayment', function (val, data, callback) {
                    var self = contractFixedEditor;
                    setEditorFirstRepaymentRepaymentFreeMonthsDependencies(
                            self.field('fixed.first_repayment'),
                            self.field('fixed.repayment_free_months'),
                            self.field('fixed.repayment_method'),
                            self);
                })
    

    So if fixed.first_repayment changes value, then you dropping into that setEditorFirst... method which does:

    that.set( firstRepayment.name(), 0 )
    

    where firstRepayment is the fixed.first_repayment field. So its setting its own value, which is triggering the change event (it has to even although its actually the same value, since you are specifically calling the field().set() method) which calls the dependent method, which called setEditorFirst..., etc. That's killing the page and I think that's resulting in what you are seeing since the browser is taking so long to process the click.

    I've got an i7 processor in this computer and the fans spin up to max when showing that form, which is a good indication of an infinite loop as well.

    Regards,
    Allan

  • rf1234rf1234 Posts: 915Questions: 46Answers: 127

    Sorry, I lost track myself I am afraid; just saw your reply for the first time! Will check that out asap. There is a lot of dependencies on that page I know - and I have it on my to do list to remove them all and then add them all back and see what happens. The "dependent" feature is great: My clients recognize it as a great advantage over my competitor's more "static" user interface. My clients can do everything in one dialogue and aren't bothered with irrelevant fields and the like - but this great feature obviously has a price ... It's getting difficult for me to deal with the complexity it creates.

    Thanks @allan. Will get back asap.

    Roland

Sign In or Register to comment.