Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-5332

Renderer's data binding will continue with notifications after source markup is destroyed



    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: Renderer
    • Labels:


      This issue was noticed during work on the metadata component - a failing version was checked in at https://github.com/jobara/metadata/tree/FLOE-116-broken-resolution (commit is https://github.com/jobara/metadata/commit/2f4fb58228493439f556d53c5606ca97f9081158 ).

      This failure can be observed by entering a new video URL and then operating one of the checkboxes (not the radio buttons) at the right panel. This issue was provoked by a bug in the configuration for the metadata component - two listeners were registered against the panel's model in two different locations, each of which triggered a call to "updateModel".
      The first of these triggered a call to refreshView in the parent component, which under the current renderer model must destroy and recreate the subcomponent - by the time the duplicate model listener executes, the target markup and component have already been destroyed. This triggers a particularly incomprehensible IoC resolution message complaining - Failed to resolve reference

      .model - could not match context with name panel from component ....

      Note that this is currently an "old-style" model component and so the listener loop during which the component destruction occurs is "fireAgglomerated" inside the old ChangeApplier implementation. This is a particularly inaccessible location and the best solution would be to wait for the framework to be rationalised somewhat so that we can deal with the issue in just one place, the new ChangeApplier. However, this would also require advanced support for a new event facility described in FLUID-5333, "abortable events"

      This issue was discussed in IRC on 24/4/14 currently logged at https://botbot.me/freenode/fluid-work/2014-04-24/ .

      This issue is related to FLUID-4890 in that at least the fix for that issue would result in a much better diagnostic, failing in the listener early with the message that the component had been destroyed.


          Issue Links



              antranig Antranig Basman
              antranig Antranig Basman
              0 Vote for this issue
              1 Start watching this issue