ICEmobile
  1. ICEmobile
  2. MOBI-202

Menu button select value hides menu

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.0 Williams
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      any

      Description

      The menuButton component displays a list of menu items but also displays a "select" menu item as a place holder. The menu item allows for the component to allow successive execution of the same menu item. However if a user clicks on the selected menu item the menu will hide.

      I'm not sure there is much we can do address the current behaviour but perhaps the JavaScript can be reworked so that we no longer need the selected state.

        Activity

        Hide
        Judy Guglielmin added a comment -

        need to be sure that the desired behaviour is well thought out.

        When I reviewed this component, the behaviour seemed relevant since it had been determined that we would be taking advantage of the <select> tag behaviour in the device and desktop browsers.
        Since cross-browser implementation meant that we would only be able to count no the 'onchange" event, we would need to reset after each use of this component and that was deemed acceptable at this time. Is that not still the case?
        Looking at overriding this behaviour and having the "Select" option keeping the menu open, would mean that the user could never close this popup selection unless they chose one of the other selection options. This could be a problem if they did not really want to trigger one of those events.
        By allowing the Select option to close the popup, they always have a "safe" out of the component.

        My understanding was that they users had a valid use-case to be abel to click on the same option twice in a row and have the corresponding jsf eventListener get triggered, so no work was put into managing the events triggered (although Select should not trigger a request and testing to ensure it does not.

        Show
        Judy Guglielmin added a comment - need to be sure that the desired behaviour is well thought out. When I reviewed this component, the behaviour seemed relevant since it had been determined that we would be taking advantage of the <select> tag behaviour in the device and desktop browsers. Since cross-browser implementation meant that we would only be able to count no the 'onchange" event, we would need to reset after each use of this component and that was deemed acceptable at this time. Is that not still the case? Looking at overriding this behaviour and having the "Select" option keeping the menu open, would mean that the user could never close this popup selection unless they chose one of the other selection options. This could be a problem if they did not really want to trigger one of those events. By allowing the Select option to close the popup, they always have a "safe" out of the component. My understanding was that they users had a valid use-case to be abel to click on the same option twice in a row and have the corresponding jsf eventListener get triggered, so no work was put into managing the events triggered (although Select should not trigger a request and testing to ensure it does not.
        Hide
        Ted Goddard added a comment -

        Although this is a customer-requested feature, it does sound unusual for a menu component. This should likely be a separate component or an application feature using a popup. It is not targeted for 1.1 Final.

        Show
        Ted Goddard added a comment - Although this is a customer-requested feature, it does sound unusual for a menu component. This should likely be a separate component or an application feature using a popup. It is not targeted for 1.1 Final.

          People

          • Assignee:
            Judy Guglielmin
            Reporter:
            Patrick Corless
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: