SJRK-400: singleFileUploader is undefined when removing media blocks

Description

In certain (as yet unidentified) circumstances, when removing a media block (audio, image, video), the block editor's singleFileUploader component is undefined by the time sjrk.storyTelling.ui.storyEditor.removeSelectedBlocks() is called.

This has only been observed in the tests for sjrk.storyTelling.ui.storyEditor and sjrk.storyTelling.base.page.storyEdit.

To reproduce:

1. Check out the tool at this exact commit: https://github.com/BlueSlug/sjrk-story-telling/tree/52e198dceae3e2aaa6a6e0334770cf9f25bdc6d5
2. Run the site via a basic HTTP server such as Browsersync
3. Navigate to the storyEditor browser tests: http://localhost:3000/tests/ui/html/ui-storyEditor-Tests.html

Expected:

Tests complete successfully

Actual:

The tests hang and an error is displayed on the developer console (see attached screenshot):

ui-storyEditor.js:295 Uncaught TypeError: Cannot read property 'resetUploadState' of undefined
    at ui-storyEditor.js:295
    at Object.fluid.each (infusion-all.js:14543)
    at sjrk.storyTelling.ui.storyEditor.removeSelectedBlocks (ui-storyEditor.js:291)
    at togo (infusion-all.js:21310)
    at HTMLButtonElement.fire (infusion-all.js:15643)
    at HTMLButtonElement.dispatch (infusion-all.js:5189)
    at HTMLButtonElement.elemData.handle (infusion-all.js:4997)
    at Object.trigger (infusion-all.js:8255)
    at HTMLButtonElement.<anonymous> (infusion-all.js:8333)
    at Function.each (infusion-all.js:360)

Environments

Infusion 3.0.0-dev.20200728T104627Z.e6aa1a341.FLUID-6145

Attachments

Comments

• Gregor Moss commented 2020-10-20T20:59:27.611-0400

  From today's discussion in the #fluid-work IRC channel, a discussion between @@Justin Obara and @@Antranig Basman around why one aspect of one of of the attempted solutions did not work:

  <Justin_o> Bosmon: an unrelated questions. For the onDestroy event, is that fired before any destructive actions have taken place? With some updates to the storytelling tool that gmoss is working on. We were looking at firing a model change, to trigger an upstream model relay, just before the component is destroyed. I think there were some errors with a relay not being available though.
  <Bosmon> Yes, onDestroy is fired before anything is torn down
  <Justin_o> Bosmon: hmmm so the model relay should have worked then
  <Justin_o> which is what I was expecting. I guess we'll have to take a look at that error again
  <Bosmon> Justin_o - relays are not torn down until the last moment before afterDestroy
  <Justin_o> Bosmon: thanks for confirming that. might have been something else... will try to remember to check this with gmoss when he's online later

• Justin Obara commented 2020-10-21T08:26:52.412-0400

  @@Gregor Moss and @@Antranig Basman I've pushed up a branch that will include the issues with using onDestroy as mentioned in the comment above. See further discussion from the fluid-work irc channel today.

• Justin Obara commented 2020-10-21T08:48:00.201-0400

  There is an underlying framework issue that prevents using onDestroy as mentioned above. See: FLUID-6558