bootstrap: JS components throws console error "Error: is transitioning"

Following the feature request #17800, the PR #17823 has been merged. It prompted several issues with the error message Error: <Component> is transitioning in the browser console of the user.

This ticket aims at centralizing those issues, gather feedback and discuss a possible solution.

Here is the issues found so far:

Moving cursor over popover quickly (#21600)
Tooltip inside modals prevent to close the modal (#21607)
User quickly triggering a component (collapse, carousel, popover etc…) animation by clicking fast on a button fast (#21704)
Changing carousel slide before the previous finish transitioning: #21960

The issue #21687 has also been reported but it’s not directly related. See comment

The original feature request and PR attempt to warn the user when he call the component API repeatedly instead of waiting for and even before making the next call. Even though this behavior is expected and documented. See comment It worth noting that the previous behavior (skip the call if it’s transitioning) is quite common and most framework works this way and expect the developer to understand the notion of asynchronous.

Unfortunately, with the current implementation (#17823) it seems we have inadvertently created more problems than we solved… In addition we have added some complexity to the code, and it seems difficult to anticipate all the potential problem that will be found.

Here is a few solutions I can think of.

1 - Revert #17823 and improve the documentation by adding a clear warning on each transition-capable module page and add more examples of events handling

(+) Remove the added complexity
(+) Work similarly to other framework that deal with asynchronous methods
(+) Avoid any future issues along the lines of (#21600, #21607, #21704)
(-) Even with a big warning on each module page in the docs, we might still have tickets like #17796

2 - Improve #17823 to throw an exception only when the call has been made from the API (and not from a trigger element)

(+) Solve #17800 and avoid tickets like #17796
(-) Keep the added complexity
(-) Might still create unexpected issues in cases where we mix API call and element trigger
(-) Might still create unexpected “module interaction” issues like in #21607

3 - Allow a method call or a trigger event on the JS components to cancel an on-going transition and a new one

(+) Solve #17800 in way that doesn’t produce console error and provide a good user experience
(+) Tooltips and Popovers already work that way
(-) Difficult to implement for modal as a call to $().modal start 2 successive transitions (backdrop then the modal itself. It would require to distinguish which transition is on going and react differently.
(-) Extremely difficult to implement for the Carousel component. As the items move independently, it would require to adapt the transition speed of each item based on their position when the transition is canceled
(-) Overall add a lot of complexity and risks for regression

Feel free to propose and discuss other potential solutions.

My hunch is that solution 1 (revert and document) might be better. The problem we try to solve is related to developers who do not read the docs or understand asynchronous functions. It feels like this issue is better solved by improved documentation, especially when the “code solution” create issues for the end user. And I think the doc can be improved in that regard. The problem I see with the “code solution” is that it will either create a constant source of bugs or become extremely complicated in order to handle every possible case. Not mentioning that it would make adding new modules/feature more complicated.

I’d love to hear the community and bootstrap team ideas/feedback/opinion.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 17
Comments: 23 (6 by maintainers)

Most upvoted comments

This issue is the most terrible moment that I have ever had with Bootstrap. In case when you should have a lot of modals on an one page and they should open\closed via sequence it’s just horrible in case if the transition can’t be aborted automatically when a new transition launches.

velidan on Apr 6, 2017

In case others need it, this is my hotfix for modals, assuming id is the modal’s id.

var that = $("#"+id);
$("body").removeClass("modal-open");
$("body").css({"padding-right": "0"});
that.removeClass("show");
that.css({"display": "none"});
$(".modal-backdrop").remove();
var bsModal = that.data('bs.modal');
bsModal["_isShown"] = false;
bsModal["_isTransitioning"] = false;
that.data('bs.modal', bsModal);

pjdufour on Feb 28, 2017

Transitions aren’t the problem here. Always going nuclear is.

You know, this whole thing looks a lot like Ember.js’s famous/notorious “calling set on destroyed object” error, where Ember.js would assume end of the world scenario happened and errored because you’ve tried to change state of object that was in gc queue. On other side, React.js authors who encountered same situation assumed that most of time that such scenario occurs, there’s likely no risk of real error happening anyway, and opted for warning instead. So React.js warns you with “hey, component that you’ve unmounted tried to change its state, see if this is an issue” when you are in dev builds, and stays quiet in prod builds.

I believe that attempting other transition within current transition should simply raise warning and don’t perform any new transition at all. In addition I would like more explicit callback API’s for those transitions, like such:

$('#muh-modal').modal('show', () => {
    this.setState({ isVisible: true });
});

rafalp on Feb 11, 2017

I’ve personally reverted this feature in my environment, on carousels only, as I need it to go into “production ready code.” This is just my opinion but it seems that this feature has added unnecessary complexity. Allowing users to skip an item in transition, in regards to carousels, can be a valid use case. Impatient users, users quickly fumbling through large carousels, etc, seems like a valid use case to me. Again I did this in my environment only, as we really want to upgrade to v4, but reverting the feature allows the carousel to work in a manner that is similar to v3.

Carousel.prototype.next = function next() {
  this._slide(Direction.NEXT);
};
Carousel.prototype.prev = function prev() {
  this._slide(Direction.PREVIOUS);
};

strikefvela on Mar 28, 2017

@vanduynslagerp Huge thanks for collating all this. Assigning this to myself so I remember to work through this tomorrow. If anyone else wants to take it, feel free.

bardiharborow on Jan 15, 2017

I have the same issue when showing tooltips on elements in a variable sidenav which shows when window is resized to small viewport sizes.

Is there a way to just ditch the transitions if it makes such a huge problem?

In my mind they are bonus but not needed. If my tooltips don’t show at all any more I’d rather not have any fancy “transitions” which shoot me in the foot.

bf on Feb 9, 2017

I made the PR which created all this issues but like @vanduynslagerp I prefer the first option because finally it’s a developer problem not a user’s problem

Johann-S on Jan 15, 2017