Noticeable and possibly degrading delay before "global commit" finishes its work in Chrome.

[RashadSaleh]

How to reproduce:

Use the following code to setup your vuex store with vuex-basement:

import Basement from 'vuex-basement';

var basement = new Basement({
  includes: [{
    path: "message",
    reactions: {
      on_change: [function(state, new_v, old_v) {
        console.log('message has changed from', old_v, 'to', new_v);
      }]
    }
  }]
});

const store = new Vuex.Store({
  state: {
    message: "Hello World"
  },
  mutations: {
    "change message": function(state, payload) {
      state.message = payload.new_message;
    }
  },
  actions: {
    "global commit": basement.global_commit
  }
});

basement.attach_to_store(store);

window.change_message = function(new_message) {
  store.dispatch('global commit', {
    type: 'change message',
    payload: {
      new_message: new_message
    }
  }).then(function() {
    console.log('done changing message in all browser.');
  });
}

Now, issue the change of message in your Chrome console after opening several tabs of your app:

change_message('hey'):

You will see "done changing message in all browser." logged and the state synced appropriately between tabs. However, this last message will take a brief but noticeable delay before it gets logged. This is especially an issue when you are chaining several global commits to happen one after the other.

I could only produce the bug in Chrome (updated to the latest version as of the creation of this issue), and it completely disappears in Firefox and Edge (also latest versions). This might be caused by Chrome being faster than other browsers which in this particular case happens to show a flaw in the library's logic that other browsers don't get the "luxury" of detecting, or it might be a bug in chrome itself.

The issue remains after multiple code rewrites and even using third party plugins (intercom.js and store.js) to handle localStorage events, and it is not clear in any obvious way how the logic produces such a bug.

Any help will be greatly appreciated.

[RashadSaleh]

Turns out the problem was caused by browsers, especially chrome, throttling javascript execution in idle tabs. This means two things:

1. This is now confirmed to not be caused by faulty logic in the implementation.
2. This remains an issue only when one wants to wait for idle tabs to complete execution, while tabs that get brought back into focus by the user (which is the "standard" scenario) stop being throttled by the browser automatically and user notices no delays whatsoever.