Consistent placement of Cancel buttons

[Ryan J Ollos <ryan.j.ollos@…>]

For most Trac pages, the Cancel buttons are consistently placed on the right.

Wiki edit:

Milestone edit:

Report edit:

The right seems the natural place to place Cancel. However, on the admin panels, Cancel is placed on the left. I suggest moving the position of the buttons on the admin panels to be consistent with the rest of Trac.

Admin Components Edit::

Patch is on the way.

[anonymous]

Consistency is good.

I would like to suggest changing the buttons to be consistent with AdminComponentEdit.png​ though. I can't speak for other platforms such as Windows or Linux but in OS X it seems the "Cancel" button always is always left of the "Okay" button or whatever button there is to affirm an action.

[Christian Boos]

On Windows, it's also very common to have the Cancel button on the right, like in most places already in Trac. So fixing it for the components admin panel seems the right thing to do.

[Ryan J Ollos <ryan.j.ollos@…>]

Patch against r11689 of the trunk.

[Ryan J Ollos <ryan.j.ollos@…>]

t11076-r11689-1.patch​ makes changes to the following pages to place the Cancel button to the right of the other submit buttons:

• Wiki delete
• Report delete
• Ticket delete
• Wiki rename
• Milestone delete
• Component/Milestone/Enum/Version/Repository edit

Instances of Cancel:

(t11076)user@debian-wheezy:~/Workspace/t11076$ grep -R --exclude-dir=.svn "_('Cancel')" .
./trac-trunk/trac/admin/templates/admin_enums.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/admin/templates/admin_components.html:            <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/admin/templates/admin_milestones.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/admin/templates/admin_versions.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/ticket/templates/milestone_delete.html:        <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/ticket/templates/report_edit.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/ticket/templates/milestone_edit.html:          <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/ticket/templates/report_delete.html:          <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/ticket/templates/ticket_change.html:      <input type="submit" name="cancel_comment" value="${_('Cancel')}"
./trac-trunk/trac/versioncontrol/templates/admin_repositories.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/wiki/templates/wiki_rename.html:          <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/trac/wiki/templates/wiki_edit_form.html:      <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/wiki/templates/wiki_delete.html:          <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/templates/attachment.html:            <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/trac/templates/attachment.html:              <input type="submit" name="cancel" value="${_('Cancel')}" />
./trac-trunk/tracopt/ticket/templates/ticket_delete.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>
./trac-trunk/tracopt/ticket/templates/ticket_delete.html:            <input type="submit" name="cancel" value="${_('Cancel')}"/>

[Remy Blank]

Just remember that the first button (i.e. here the leftmost) will be activated when pressing ENTER in a text input field. For wiki pages, previewing in that case is a natural thing to do. For edits, it's probably fine to save on ENTER. For deletes, however, I would say that the safe thing to do should be to cancel (although in ticket_delete.html it's a non-issue, as there's no text input).

[Christian Boos]

Ah right, I remember that we discussed it before (#6521). I didn't realize the default was depending on the order… Isn't there a better way? Well, ​apparently not. Maybe we could indeed use a bit of CSS to move the Cancel button to the right.

[Remy Blank]

I still think a few of the admin panels could have their "Save" buttons moved to the left as default. It happened to me more than a few times that I edit something, press ENTER only to cancel the edit. We just have to be careful in the few cases where data loss could happen.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to rblank:

I still think a few of the admin panels could have their "Save" buttons moved to the left as default. It happened to me more than a few times that I edit something, press ENTER only to cancel the edit.

I agree that Save when pressing enter is the more expected behavior. It's also the behavior that currently exists for Milestone edit and Report create. Perhaps a more descriptive info message would help too though. For example, when renaming a component and changing it's owner, we currently see:

close Your changes have been saved.

We could show the exact changes that were just saved:

close Your changes to component1 have been saved:

• Name changed from component1 to component3.
• Owner changed from somebody to nobody.

Related: #11080.

We just have to be careful in the few cases where data loss could happen.

If we all agree with putting the Cancel on the right for the admin pages, it looks like we have only one possible case of "data loss":

• Wiki delete: no input elements.
• Report delete: no input elements.
• Ticket delete: no input elements.
• Wiki rename: new_name text input and redirect checkbox; this case seems similar to the admin panels.
• Milestone delete: Press enter while the retarget checkbox is the active element, milestone will be deleted.

It looks like Milestone delete is the only case to worry about.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

• Milestone delete: Press enter while the retarget checkbox is the active element, milestone will be deleted.

Another note about this: clicking on the checkbox and then pressing enter doesn't activate the first form button on submit. You must tab to the checkbox element and press enter.

I haven't had any luck using CSS to reorder the buttons without having them also float to the right. Besides coming up with a way to reorder the buttons using CSS, it seems like there are a few options here:

• Disable submit when hitting enter on the checkbox using JavaScript.
• Do nothing since this is a corner case that is unlikely to cause many users an issue.
• Reorder the buttons with JavaScript.

Changes so far:

• ​24541cb7: Puts the Cancel button on the right (same as attachment:t11076-r11689-1.patch​).
• ​578de3cb: Removes some unused (overridden) CSS (this has been around for awhile). I didn't edit margin because margin-left of 0em looks better to me than 1em.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

Replying to Ryan J Ollos <ryan.j.ollos@…>:

• Milestone delete: Press enter while the retarget checkbox is the active element, milestone will be deleted.

Another note about this: clicking on the checkbox and then pressing enter doesn't activate the first form button on submit. You must tab to the checkbox element and press enter.

This same behavior currently exists on the admin ticket view panels. For example, on the Admin Component panel:

1. Tab to the checkbox for component1.
2. Press the Spacebar to check the box.
3. Press Enter.

component1 will be deleted. It seems like we should swap the order of Remove select items and Apply changes.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

• ​24541cb7: Puts the Cancel button on the right (same as attachment:t11076-r11689-1.patch​).

Note that it's not exactly the same as the first patch, since I haven't applied the change to the Milestone delete page, pending a decision on how to deal with that one.

[anonymous]

cant you just add a "confirm to delete / are you sure" popup/messagebox?

[Ryan J Ollos]

To summarize a few things from this ticket:

• I'll defer the enhancement described in comment:8 to another ticket.
• The issue with the Milestone delete page that is described in comment:8 is no longer relevant because the Retarget checkbox is being removed (comment:38:ticket:5658).

I've prepared the proposed changes for review in rjollos.git:t11076.

One side note regarding the small bit of CSS refactoring first proposed in comment:9. The milestone class is only used on a few pages:

(t11076)user@ubuntu:~/Workspace/t11076$ grep -R --exclude-dir="tests" "class=\"milestone\"" .
./teo-rjollos.git/trac/ticket/templates/milestone_delete.html:    <div id="content" class="milestone">
./teo-rjollos.git/trac/ticket/templates/roadmap.html:        <div py:for="idx, milestone in enumerate(milestones)" class="milestone">
./teo-rjollos.git/trac/ticket/templates/milestone_view.html:    <div id="content" class="milestone">
./teo-rjollos.git/trac/ticket/templates/milestone_edit.html:    <div id="content" class="milestone">

After inspecting all of those pages, I found that:

• The .milestone .date selector was not being used because the .milestone .info .date matches for the applicable elements on the pages where the milestone class is used.
• The first of the two .milestone .description selectors could be deleted, because the second overrides the first.

In both cases, it appears the duplication of the selectors was just overlooked when the first of the two selectors was modified in [1251].

[Ryan J Ollos]

Committed to 1.0-stable in [11882:11883] (merged to trunk in [11886]), followed by a minor refactoring in [11884:11885] (merged to trunk in [11887]).