654277 - a test writer should be able to add another step to a testcase without using the mouse

Status: VERIFIED FIXED

(Mozilla QA Graveyard :: MozTrap, enhancement)

Description

[Cameron Dawson [:camd]]

Need some kind of hotkey, or perhaps hitting "tab" while on the "expected" field of the first step will create a new step.  Or ctrl+enter or something.

Comment 1

[Cameron Dawson [:camd]]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/12921589

Comment 2

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
I was thinking a nice way this could work would be this:

1. On entering the page, it initially shows action/expected for 2 steps.  
2. The user can tab from field to field.  When they type step 1 action, then step 1 expected result, they can hit tab and it will take focus to the action for step 2.  
3. As soon as focus moves to the action field for step 2, then fields for a 3rd step are created, and so on.  

This way no hotkey is needed to create a new step.  They just get it, if they need it.

Comment 3

[Cameron Dawson [:camd]]

Jonny Gerig Meyer changed story state to started in Pivotal Tracker

Comment 4

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Carl & Eric: The new auto-add is implemented, but I'd be happy for you both to test it and see if it works as you'd expect. The only thing I don't like is the tabindex for remove-links (because they're appended to the row in the markup, you tab to the remove link for a row AFTER that row, which is weird). I'm tempted to just remove them from the tabIndex, but if that's not ideal (for accessibility reasons), I'm curious what you guys would propose for a better solution.

Eric: I'm passing this to you, because I think it's ready for you to wireframe inserting a row in between existing rows.

Comment 5

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
jonny: looks great! I think the tabIndex thing we can just leave as it is for now. I did notice one minor issue: if you disable HTML5 form validation and submit the form with something wrong (like blank name or description or a step with blank expected result), the reloaded page has an extra blank step that isn't grayed out or made non-required, which you have to then delete before you can submit the form successfully. Made you a task.

Comment 6

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
carl: should be fixed now. feel free to tell me i'm wrong, or broke something else. :-)

Comment 7

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
carl&eric: JS is in place, and seems to work great. @carl, I did notice that the form always redirects to #single after submission; maybe it did that before, but I didn't notice it before and wanted to make sure that's intentional/unavoidable.

Comment 8

[Cameron Dawson [:camd]]

Eric Meyer changed story state to finished in Pivotal Tracker

Comment 9

[Cameron Dawson [:camd]]

Carl Meyer changed story state to delivered in Pivotal Tracker

Comment 10

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
jonny: I could remove the #single and rely on that being the default, but not sure that's worth it; the bulk form will still submit to #bulk. That's needed for error-reload to work correctly; unfortunately the browser keeps the hash tag in place when it gets a redirect, which is why we still get the useless #single/#bulk on successful redirect. I don't know of any way we can avoid this as long as we're doing the two-forms-in-slideshow thing and want error-reload to work. Shouldn't be a problem unless we introduce an actual #single or #bulk on the test case manage list page.

Comment 11

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to accepted in Pivotal Tracker

Comment 12

[Matt Brandt [:mbrandt]]

Bumping to verified as [qa-] due to age of bug, shipped.