ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keta Patel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-14574) multiple clicks on "Next" button causes skipping of steps while installing a cluster
Date Tue, 19 Jan 2016 03:22:39 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-14574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106185#comment-15106185
] 

Keta Patel commented on AMBARI-14574:
-------------------------------------

[~aantonenko], I tried out a couple of different ways from the suggestions you mentioned as
follows:
Attempt 1 and 2 are taken from AMBARI-12737. The fix in this Jira resolved the issue of keeping
the steps following the current step disabled, so that a user could navigate to any step before
the current step but not to the ones after the current step. I used the 'isStepDisabled' object
used in this fix for the attempts below.
Attempt 3 uses 'transitionInProgress' property.

Attempt 1 (using AMBARI-12737):
**********
Using "if a step is disabled or not" as the check:

If we use App.router.installerController.isStepDisabled.value for a step, it will be false
if that step is the current step or a step that comes before the current step. So if this
check is used in the controller’s ‘submit’ function for a step, it will not filter out
the duplicate Next button clicks for that step. This is because a duplicate Next button click
will be calling the same controller ‘submit’ function. App.router.installerController.isStepDisabled.value
for a step stays ‘false’ from this point onwards unless the user jumps back to an earlier
step. So this check fails in the controller.

!attempt_1_controller.png!

This check also fails for steps that call the installer’s ‘next’ function directly.
For example, in case of step1, the installer’s ‘next’ function is called on Next button
click.
App.router.installerController.get(‘isStepDisabled’).findProperty(‘step’,1).get(‘value’)
will always be false if the execution reaches this point in the installer. Hence, this check
won’t be effective to filter out duplicate calls for steps where installer’s ‘next’
function gets called on the Next button.

!attempt_1_installer.png!


Attempt 2 (using AMBARI-12737):
**********
Using "if the current step is the one meant to call the submit/next functions" as the check:

if we use App.router.installerController.get('currentStep') to ensure that a submit button
click was meant for the current step, then it works correctly in cases where the controller
is called on Next button click. The following example checks for the current step in the ‘submit’
function of the controller for step0. Any duplicate calls for step0 will be filtered out by
this check.

!attempt_2_controller.png!

In cases where the Next button directly calls the installer ‘next’ function, this check
doesn’t work because a duplicate call from installer’s ‘next’ will also call installer’s
‘next’ for the following step. Hence the check fails. This can be seen in the following
example where ‘step1’ calls installer’s ‘next’ directly. A duplicate call on step1’s
Next button will also call the installer’s ‘next’ for the ‘currentStep’ which becomes
‘step2’ after ‘router.transitionTo(‘step2’)’ line.
!attempt_2_installer.png!


Attempt 3 (using 'transitionInProgress'):
**********
Using "transitionInProgress to check if a transition is already in process before processing
a Next button click" as the check:

I tried re-using the ‘transitionInProgress’ variable to check for duplicate Next button
clicks. The trunk uses ‘transitionInProgress’ only in the installer when the router is
transitioning to the next step. This variable is not used in controllers of the steps. Since
the Next button clicks call the controller’s ‘submit’ function for some steps and installer’s
‘next’ function for the other steps, we will not have uniformity in terms of where to
set or reset the property. If we use this property in the controller’s ‘submit’ function,
then we need to remove this check from the installer’s ‘next’ function for that step
(in case where that step has this check in the installer) in order for the transition to proceed.
But this removal could allow multiple clicks from the previous steps to propagate through
this step. Hence, we can’t remove the ‘transitionInProgress’ checks from the installer’s
‘next’.

!attempt_3_adding_check_for_step1.png!

!attempt_3_removing_check_from_step3.png!

Please correct my understanding and approach to fix this issue.

> multiple clicks on "Next" button causes skipping of steps while installing a cluster
> ------------------------------------------------------------------------------------
>
>                 Key: AMBARI-14574
>                 URL: https://issues.apache.org/jira/browse/AMBARI-14574
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-web
>    Affects Versions: 2.1.1
>            Reporter: Keta Patel
>            Assignee: Keta Patel
>         Attachments: AMBARI-14574.patch, attempt_1_controller.png, attempt_1_installer.png,
attempt_2_controller.png, attempt_2_installer.png, attempt_3_adding_check_for_step1.png, attempt_3_removing_check_from_step3.png
>
>
> On installation wizard, multiple clicks on the "Next" button can cause skipping of steps.
The timing of the 2nd click decides if that click will be processed again or not. The following
JIRAs had the same issue:
> AMBARI-7195
> AMBARI-7315
> The fix for the above issues helps to resolve most part of the problem. But if the user
happened to click again at the point when the last callback function has just completed (and
thus, has made the "Next" button clickable again) but the next step has not yet completed
its rendering, then the 2nd click gets processed again. The "current step" was already updated
in the code to point to the next step, from the 1st click. So when this 2nd click calls the
"next" function in the router, the subsequent step of the "current step" gets set as the current
step. As a result we skip steps.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message