Qualify events by namespace "bsDatepicker"

[ZekeLu]

Otherwise, it will be at the risk to pollute events from other controls

This fiddle illustrates how event namespace works

[tkrotoff]

+1, I'm encounting some bugs due to datepicker having no namespace for events.

I have a datepicker inside a collapse. Each time the user clicks to display the datepicker it also triggers the 'show' event for collapse.

Another pull request was made quite some time ago: https://github.com/eternicode/bootstrap-datepicker/pull/337

[1000hz]

:+1:

The lack of namespaced events is causing datepicker events to trigger the event handlers of a parent container component (e.g. modals, collapse elements, etc.)

[bramchi]

nice improvement!

[bmchrist]

:+1: This is causing issues for us as well when nested within a bootstrap modal (triggering show.bs.modal, etc)

[rodsouto]

thanks @ZekeLu , I was having problems with bootstrap modals too :+1:

[alexandrejobin]

is there any plan to include this kind of patch to the trunk? On my side, to solve the problem, i added the bootstrap namespace style "show.bs.datepicker" and "hide.bs.datepicker" and it solved the problem.

show: function ()
{
    if (this.element.attr('readonly'))
        return;
    if (!this.isInline)
        this.picker.appendTo(this.o.container);
    this.place();
    this.picker.show();
    this._attachSecondaryEvents();
    this._trigger('show.bs.datepicker');
    if ((window.navigator.msMaxTouchPoints || 'ontouchstart' in document) && this.o.disableTouchKeyboard)
    {
        $(this.element).blur();
    }
    return this;
},

    hide: function ()
    {
        if (this.isInline)
            return this;
        if (!this.picker.is(':visible'))
            return this;
        this.focusDate = null;
        this.picker.hide().detach();
        this._detachSecondaryEvents();
        this.viewMode = this.o.startView;
        this.showMode();

        if (
            this.o.forceParse &&
            (
                this.isInput && this.element.val() ||
                this.hasInput && this.element.find('input').val()
            )
        )
            this.setValue();
        this._trigger('hide.bs.datepicker');
        return this;
    },

[acrobat]

@skoub Yes we want to fix this long lasting issue, but changing the events would mean a BC break. So we are figuring out if we are going that in a 1.X release (which is agianst the "rules" of semver) or this should wait for a 2.0

[alexandrejobin]

@acrobat you should wait for the 2.0. But i think you should not wait too long to release a 2.0 since that the datepicker is not fully fonctionnal with the boostrap 3 and people (like me) will look elsewhere to find a datepicker that will work perfectly with BS3.

[acrobat]

Yes indeed that true! 1.4 should be out by the end of the month and then we should have atleast a few bugfix releases and maybe also a 1.5 but nothing should hold us back to already start development on a 2.0 version.

I will discus this with the team and so we can start picking goals for that 2.0 release. Goals we need to develop or get help from the community in developing these features/changes

[alexandrejobin]

great! maybe you could add a section on the the description page to explain this bug and how we can apply the correction ourself until the v2.0?

[acrobat]

Good idea @skoub, do you maybe want to send a pr for that? Otherwise I will add it to docs before the 1.4 release!

[alexandrejobin]

@acrobat, i prefer to let you decide how to explain it in the doc because i don't know where you want to go with the events namespace convention.

Ideally, i would put something that have good chance to appear in the next version. Would it be "show.bs.datepicker" or maybe "shown.bs.datepicker" since that the picker is already visible when the event is fired.

[jwt02180]

I'd just like to add that I came across this issue with the event conflict between this and bootstraps modal. It was unexpected since there's no documentation of this being a possibility, and I only found out it by looking through the issues here.

It'd be much appreciated if something was added to the docs about this until it's fixed in a future version.

[whaus7]

Had the same issue. That nameSpace fix worked like a charm for me. Will I need to update anything with my datepickers or no?

[LastExile16]

I can't believe this issue existed since 2014 and not solved by datepicker team :/

[acrobat]

@LastExile16 this is a foss project so we all can only spend the free time we have and the time we have left after other personal priorities.

I've personally been busy in my personal life and had some vacation in the last months. I'm going to try to spend some more time on the project in the coming months and have the last minor release out (1.7). After that release we can start working on 2.0 and have the namespace issue resolved.

[pvdlg]

The namespace should be added here as well.

[sambenne]

2023 and this is still not fixed

[TomePale]

Any chance for adding namespace fix soon ?