Uploaded image for project: 'Apache Flex'
  1. Apache Flex
  2. FLEX-33742

CalloutButtons inside another CalloutButton or Callout opened contents closeDropDown calls close the parent callout content

Details

    Description

      When using a callout button inside the callout content of a different callout button I am having an undesired effect.

      Calling the dropdown method of the child callout button (the one placed at the callout content) is closing its callout content (as desired) but also closing the parents callout content.

      CalloutButton instances are to be closed using the closeDropDown() method which is causing the problem. Calling it for one instance is closing all instances. I think it was programmed that way thinking there would never be 2 CalloutButton instances opened at a time, but It really happens when you use CalloutButtons inside the contents that are displayed when an instance of CalloutButton is opened.

      Attachments

        1. CalloutButtonIssueAndWorkaround.fxp
          21 kB
          Stepan Hilbert

        Issue Links

          Activity

            I have checked the source code, and the bug seems to be in DropDownController.systemManager_mouseDownHandler(), which makes an incorrect assumption.
            It assumes that if a mouse down event occurs OUTSIDE of the callout, then the callout should be closed.
            This is true, unless the mouse down occurs INSIDE ANOTHER Callout, in which case, it should be ignored.
            See code below:

            DropDownController.as
            /**
                 *  @private
                 *  Called when the systemManager receives a mouseDown event. This closes
                 *  the dropDown if the target is outside of the dropDown. 
                 */     
                mx_internal function systemManager_mouseDownHandler(event:Event):void
                {
                    // stop here if mouse was down from being down on the open button
                    if (mouseIsDown)
                    {
                        mouseIsDown = false;
                        return;
                    }
            
                    if (!dropDown || 
                        (dropDown && 
                         (event.target == dropDown 
                         || (dropDown is DisplayObjectContainer && 
                             !DisplayObjectContainer(dropDown).contains(DisplayObject(event.target))))))
                    {
            
            maurice.amsellem Maurice Amsellem (old) added a comment - I have checked the source code, and the bug seems to be in DropDownController.systemManager_mouseDownHandler(), which makes an incorrect assumption. It assumes that if a mouse down event occurs OUTSIDE of the callout, then the callout should be closed. This is true, unless the mouse down occurs INSIDE ANOTHER Callout, in which case, it should be ignored. See code below: DropDownController.as /** * @ private * Called when the systemManager receives a mouseDown event. This closes * the dropDown if the target is outside of the dropDown. */ mx_internal function systemManager_mouseDownHandler(event:Event):void { // stop here if mouse was down from being down on the open button if (mouseIsDown) { mouseIsDown = false ; return ; } if (!dropDown || (dropDown && (event.target == dropDown || (dropDown is DisplayObjectContainer && !DisplayObjectContainer(dropDown).contains(DisplayObject(event.target)))))) {
            maurice.amsellem Maurice Amsellem (old) added a comment - - edited

            If it's not possible to determine that the mouse event occurs inside another Callout, then maybe the developper could manually indicate which nested callouts should be ignored.
            this could be done using DropDownController.hitAreaAdditions property. However, it's not currently public.
            So maybe adding a new hitAdditionProperties public property to Callout to make that possible.
            What do you think ?

            maurice.amsellem Maurice Amsellem (old) added a comment - - edited If it's not possible to determine that the mouse event occurs inside another Callout, then maybe the developper could manually indicate which nested callouts should be ignored. this could be done using DropDownController.hitAreaAdditions property. However, it's not currently public. So maybe adding a new hitAdditionProperties public property to Callout to make that possible. What do you think ?
            stepan Stepan Hilbert added a comment -

            I'm experiencing what I believe is the same issue when interacting with a DropDownList inside a CalloutButton.

            It seems to me that this is caused by two issues in CalloutButton/DropDownController - see the attached workaround.

            stepan Stepan Hilbert added a comment - I'm experiencing what I believe is the same issue when interacting with a DropDownList inside a CalloutButton. It seems to me that this is caused by two issues in CalloutButton/DropDownController - see the attached workaround.

            People

              Unassigned Unassigned
              havelillo Carlos Velasco Blanco
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated: