Most appropriate sub-area of p5.js?

• Core/Environment/Rendering ( Initialization )

Details about the bug:

• p5.js version: 1.0.0
• Web browser and version: Chrome 79.0.3945.88
• Operating System: Ubuntu 18.04
• Steps to reproduce this:

Please bear with me this is going to be a large description 😅 .
TL;DR is that there apparently seems to be some kind of a race condition with the initialization in instance mode when p5 is run alongside p5.sound library and in the presence of some large extension like Grammarly.
This could also happen with other p5 libraries and with other large browser extensions.

let x = 0;
let sketch = function(p) {
  p.setup = function() {
    x =1;
  }; 
  p.draw = function() {
    console.log(x);
  }
};
let mp5 = new p5(sketch);

I would expect to see the value 1 repeatedly printed on my console. Which is what it does in Incognito mode or with Grammarly disabled. But when Grammarly is present, I get 2 . This would mean that the setup function is running twice.

Interestingly for this sketch,

let sketch = function(p) {
  p.setup = function() {
    throw new Error();
  };
};
let mp5 = new p5(sketch);

I get two errors on the console.

The stack traces of the errors are different though they happen on the same line.

I did a little digging. Here's what I found:
In both stack traces, the setup function is called from runIfPreloadsAreDone, which can be either called from _start or _decrementPreload. runIfPreloadsAreDone checks the value of context._preloadCount and if it is 0, it runs the setup function. _incrementPreload increases the value of _preloadCount by 1, whereas _decrementPreload decreases it by 1.
The _start function is called when the window load event fires. So with this I ran the debugger and here is the order of execution I found in my normal browser window ( with extensions enabled )

1. _incrementPreload ( called from p5.sound.js ) preloadCount becomes 1
2. _decrementPreload ( called from p5.sound.js ) preloadCount becomes 0
3. runIfPreloadsAreDone ( called from _decrementPreload )
4. setup ( as preloadCount was 0 )
5. Window load event happens
6. _start ( was listening for the window load event )
7. runIfPreloadsAreDone ( called from _start )
8. setup (called for the second time :( ) ( as preloadCount was 0 )

Here's the flow when extensions are disabled:

1. _incrementPreload ( called from p5.sound.js ) preloadCount becomes 1
2. Window load event happens (happens early probably because no large extensions to wait for)
3. _start ( was listening for the window load event )
4. runIfPreloadsAreDone ( called from _start ) (setup does not run as preloadCount is 1)
5. _decrementPreload ( called from p5.sound.js ) preloadCount becomes 0
6. runIfPreloadsAreDone ( called from _decrementPreload )
7. setup ( as preloadCount was 0 ) ( setup runs only once, as it should )

I tried this in firefox (doesn't have any extensions installed) and while running normally I get the stacktrace of the second error, but it turns out I can actually make it switch to the first error's stack trace if I just wait for a while in the debugger.

I don't know if this is a problem with p5 or p5.sound or with Grammarly. I think it is a race condition with p5 which can be solved somehow. This is kind of a tricky bug which may be hard to reproduce but can give some really unexpected results for some users if they have extensions enabled. If someone else can take a look , please do.

EDIT: If it is confirmed that this actually is a bug, the fix can be quite easy perhaps by using _setupDone or something as a mutex lock.