Explanation of the problem behind #33629

In PR #31285 the following code has been added:

this.eventEmitter.emit((responseObject.upgraded ? 'Module Upgraded' : 'Module Installed'), elem);

The event is then catched in line 229 which calls installHandler(event) which calls updateModuleStatus(event)

Function updateModuleStatus() is supposed to update the object modulesList which model the modules listing in the BO page. As you can see on lines 245, 246... it attempts to extract many data properties from this event input:

  updateModuleStatus(event) {
    this.modulesList = this.modulesList.map((module) => {
      const moduleElement = $(event);

      if (moduleElement.data('tech-name') === module.techName) {
        const newModule = {
          domObject: moduleElement,
          id: moduleElement.data('id'),
          name: moduleElement.data('name').toLowerCase(),
          scoring: parseFloat(moduleElement.data('scoring')) ...

The problem is that the input does not contain these data properties. It only contains one: tech-name. No id, name, version...

So we have a JavaScript error Uncaught TypeError: Cannot read properties of undefined (reading 'toLowerCase') and the page JS crashes. The page remains stuck, no JS action works anymore and the user cannot close the modal window.

Explanation of the fix

In my PR I simply modify function updateModuleStatus() and, before the moduleList is being updated, I verify the expected data is provided. I added a check (moduleElement.data('version') !== undefined) which will be triggered in the usecase above. If event only contains tech-name and no id, name, version... it will not enter the loop.

This is a quick fix that absolutely does not solve the root problem.

Why I did not fix the root problem

At first I thought the root problem was that event was not correct. It should contain id, name, version... and I thought the right fix was to provide these informations in line 748.

However then I had a look at the other places in the code where the event (or another that triggers updateModuleStatus()) is being thrown. You can see them here or here.

Did you notice? When Module installed event is thrown, the code passes the jQuery element jqElementObj.closest(".${alteredSelector}");. This element contains id, name, version as data attribute. This is the data I need for my usecase. But where does it come from? When was provided this data?

This data was actually provided from the start, when the page was loaded first. It was there since the beginning. It was not provided by an ajax call. Looking more precisely, I realized that this back-office page does NOT handle the usecase "if I add a module, the module list gets populated".

Modules that are already present on the disk already belong to this list so their data attribute is populated. They do not get "added" to the list. The problem is when BO user uses the dropzone to add a new module. It is not added to the list (and consequently it does not have the data I need). Right: today, as a back-office user, if you use the dropzone to add a new module to the list, the interface tells you "youhou! install was successfull!" you close the modal window and... the list has not changed. You need to refresh the page to see your new module appear.

As of today, the modules listing on the back-office page is not capable of adding new items. You can modify items, you can delete some... but it does not support adding new items. You need to refresh the web page to see your new module appear in the list, when the list is rebuild from scratch. So the data is never added if you upload a new module. So I will never be able to grab my data and send them to updateModuleStatus() : it's not even here from the start!

And this is the real problem. The behavior of this modules listing on this back-office page, the behavior of this modulesList object is missing one usecase: how to handle "adding a module via the dropzone". It was simply not implemented 😁 the code was never written. And that is why I don't have the data I need for the function

When someone does a PR to correctly handle the "adding a module via the dropzone" usecase, he will properly fetch the new module data, populate the modulesList and the DOM. That will probably solve the issue naturally.

This PR is a simple workaround to avoid blocking the modal window. It will allow users to use the back-office page but the underlying problem remains: "adding a module via the dropzone" on this back-office page is not handled properly. The modules listing is not updated, the user needs to refresh the page. When this usecase is solved, the issue #33629 will be really solved.