FLUID-4532: Reorderer instantiated using IoC throws error when ariaLabeller tries to create liveRegion element

Metadata

Source
FLUID-4532
Type
Bug
Priority
Critical
Status
Closed
Resolution
Fixed
Assignee
Antranig Basman
Reporter
Anastasia Cheetham
Created
2011-11-01T14:13:29.905-0400
Updated
2012-01-20T16:48:41.217-0500
Versions
  1. 1.4
Fixed Versions
  1. 1.5
Component
  1. Framework
  2. IoC System

Description

When a Reorderer component is created through the IoC system (as a subcomponent of something, as opposed to a direct call to the creator function), the act of moving an element results in an error. The error occurs in fluid.ariaLabeller.generateLiveElement(): 'that' is undefined. The generation of the live element occurs as part of fluid.updateAriaLabel(), which calls the ariaLabeller's update() function.

I'm not quite sure whether this an error in the IoC system, or in the ariaLabeller itself. Everything is fine when the reorderer is instantiated "manually" (as is the case in the demos).

Comments

  • Anastasia Cheetham commented 2011-11-01T14:16:46.715-0400

    The attached patch (FLUID-4532.patch.txt) adds a unit test that provokes the error.

  • Anastasia Cheetham commented 2011-11-01T14:24:21.676-0400

    I showed this problem to Yura, and he was actually surprised that in the "working" case (i.e. when the Reorderer is instantiated manually), the ariaLabeller makes onto the thatStack at all. I was also curious about that, and still can't figure it out.

  • Antranig Basman commented 2011-11-13T02:37:30.475-0500

    This implementation should never have been using IoC - this looks like a grievous conceptual error left over from some cleanup after CSpace/1.3 work of late last year. As well as running into the FLUID-4192 "broken trees" issue, this unacceptably exposes users of FluidView.js onto a dependence on the IoC system. It should be possible for anyone to use the aria labeller without including IoC - I have reverted the impl onto an old-fashioned "unicast" event for the time being which will still enable this strategy to be customised as per the apparent original intention.

    To answer the previous conundrum, if there was not any instantiator allocated at the time the component was constructed, the framework would automatically bring one into existence (as part of the "withInstantiator" startup workflow) holding just the parent component (the aria labeller). This behaviour is clearly inconsistent, which is the reason for the FLUID-4192 report in the first place. This will be cleared away as part of the FLUID-4392 work.

  • Michelle D'Souza commented 2012-01-20T16:48:41.215-0500

    Merged into the project repo at 1e7f0d8f071a69ef5d9cd75e18fc0fe3da170622 with several framework change issues:

    FLUID-4525
    FLUID-4532
    FLUID-4537
    FLUID-4539
    FLUID-4564
    FLUID-4563
    FLUID-4568