Closed Bug 452806 Opened 17 years ago Closed 17 years ago

Status drop down makes it too easy to resolve a bug by accident

Categories

(bugzilla.mozilla.org :: General, defect)

Product:
bugzilla.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: samuel.sidler+old, Unassigned)

References

Details

Having the status drop down at the top of the page makes it too easy to change the status of the bug. It's now something that could end up getting focus and making a change on it is as simple as pressing the down arrow, something that's easy given how you might want to scroll a page. I've already seen an experienced bug triager (hi Smokey!) mark a bug as FIXED by accident. It's *much* easier to do so now that changing the status no longer involves a radio button. You say good thing. I say bad thing.
In addition, when one _really wants_ to resolve a bug, you now need to set the status to RESOLVED (two clicks) to make the possible resolutions appear, then select your resolution in the other dropdown (zero or two more clicks). Formerly, it was just one click (on the radiobutton) to mark the bug FIXED, or two (click on the dropdown arrow then select the resolution; the radiobutton automatically got selected) for other resolutions; for DUPLICATE it used to be enough to fill the input box, now you first must click "Mark as Duplicate" (I'm not counting the click on Commit, which hasn't changed with the upgrade). As an (amateur) triager, I'm feeling that the Bugzilla devs are throwing wrenches into my cogs.
OS: Windows Mobile 6 Professional → All
Hardware: DEC → All
The other advantage of the old position was that you're almost always making a comment when resolving a bug (why it's INVA, DUPE, or a checkin comment with FIXED), so the two related actions were right next to each other. In addition to accidentally resolving bugs, I'm afraid I'm now going to start making the closing comment and forgetting to to actually change the status way up at the top....
Maybe unify these fields in the dropdown? That would help with the multiple-clicks to close issue. EG, one dropdown with the choices of "NEW, ASSIGNED, RESOLVED FIXED, RESOLVED INVALID, RESOLVED WONTFIX" etc. The radio buttons were a nightmare and full of fail -- I've clicked the wrong one myself multiple times, and they were awkward UI. We should fix up the current scheme, not revert the blob of radio buttons. (In reply to comment #0) > Having the status drop down at the top of the page makes it too easy to change > the status of the bug. Can you expand on this? How is it any different than any other field at the top of the page (even in the format from vefore the upgrade)?
In reply to comment #3: Talking of radio buttons (and the checkboxes that went with some of them), where is the checkbox to set the assignee & QA back to default? I bet "serious" SeaMonkey people like Serge Gautherie will even be more hurt than me by the disparition of that one.
In reply to comment #4: Ah, I see, it's hidden by default, and you have to click both "edit" links then both checkboxes, to what formerly you could do in one click. Wrenches into our cogs indeed.
Another disadvantage of the status <select> is that if you accidentally switch it to DUPE mode, you can't un-switch it without a shift-reload, which requires you to lose everything else you've done. In the old model, it was trivial, and lossless, to undo this sort of accidental edit.
(In reply to comment #3) > (In reply to comment #0) > > Having the status drop down at the top of the page makes it too easy to change > > the status of the bug. > > Can you expand on this? How is it any different than any other field at the top > of the page (even in the format from vefore the upgrade)? Sure. It's more of a mental thing. When I'm looking at the bug, I'm likely to change the resolution without reading all the comments and based on what I think I know (say, for example, I read my bugmail, open a tab, and change the resolution without noticing a new comment has come in). Additionally, for users who tab a lot and try to navigate with a keyboard, this makes it easy to accidentally move up and down in the select without meaning to. Or perhaps you meant to change the next select. Or or or...
(In reply to comment #5) > Ah, I see, it's hidden by default, and you have to click both "edit" links then > both checkboxes, to what formerly you could do in one click. Wrenches into our > cogs indeed. With the old UI, you couldn't change the status of a bug and reassign at the same time, nor could you reassign resolved bugs. Now both actions are separate. And I doubt you reassign to default assignee and QA very often. (In reply to comment #6) > Another disadvantage of the status <select> is that if you accidentally switch > it to DUPE mode, you can't un-switch it without a shift-reload, which requires > you to lose everything else you've done. Wrong! Change the status of the bug back to its original value. The "duplicate" field goes away.
Status: NEW → ASSIGNED
I think the old place on the bottom was better for it forces you to scroll through (and read!) the comments before you can resolve the bug, even if you are pretty sure that you know it's a duplicate by only reading the summary. Now you have to scroll back upwards again to resolve the bug.
(In reply to comment #8) > And I doubt you reassign to default assignee and QA very often. Actually, this is important on BMO when moving bugs between products/components (notably due to people watching the default QA field for their component). I hope these fields are reassigned by default when moving?
(In reply to comment #8) [...] > And I doubt you reassign to default assignee and QA very often. [...] I don't, at the moment, but I've seen people who do; and when I do it's usually within the frame of "bug triage campaigns" which are currently in fashion with SeaMonkey (while preparing version 2 and deciding what to do with all those old bugs which haven't even been touched since the day SeaMonkey was created and inherited all the MozSuite bugs). IOW, when I do it's for many bugs one after another.
(In reply to comment #10) > Actually, this is important on BMO when moving bugs between products/components > (notably due to people watching the default QA field for their component). I > hope these fields are reassigned by default when moving? Yeah, they are. Try it by changing the product. It does some fancy JS stuff to change it.
How can this bug be in the ASSIGNED state when assigned to "nobody"? It was changed by LpSolit so I doubt it was due to the very flaw this bug is complaining about, but then again the irony would be delicious so I kind of hope is was.
Having the changed fields marked with color or a small icon until committing could be helpful.
(In reply to comment #14) > Having the changed fields marked with color or a small icon until committing > could be helpful. or, once again, having the status fields at the bottom (or the changes to them at the bottom) so at least you would _see_ them when clicking Commit.
(In reply to comment #13) > How can this bug be in the ASSIGNED state when assigned to "nobody"? Because in comment 6, Smokey said we couldn't change the bug status back after clicking "Mark as duplicate". But I could clearly change it back, and set it to ASSIGNED. Though the NEW -> ASSIGNED transition. But I admit I didn't pay attention to the initial bug status of this bug. :) Is that what you are complaining about in your comment?
The issue about the "Commit" button placement should probably be spun off to another bug (if it isn't already) -- with everything but the comment field now controlled at the top of the page, it might be worthwhile to have a second "Commit" button available up there. As originally filed, I'd suggest this bug be WONTFIX. I don't think the status dropdown is any more special than all the other fields that could potentially be accidentally changed. It's not focused by default and it's not in the tab-select order. Putting the status at the end of the page in hopes it forces users to read everything before making changes just doesn't sound like a good interaction. But I suppose folks want to continue discussing other tangentially-related issues around hilighting changes, changing QA/Assignee fields, multiple clicks, etc. :)
Status: ASSIGNED → NEW
One of the things that happens a lot on Bugzilla is the accidental changing of various bug fields (e.g., person A loads version 1 of bug, person B makes changes and commits version 2 of bug, person A does a normal reload to avoid a mid-air, but since it's not a shift-reload, the fields are still set to their version 1 states, and then when person A commits, many fields are reverted to their version 1 state). Although this is not a new problem for Bugzilla, the bug status usually did not fall prey to this in the past (because the available radio options would change), but now it does.
(In reply to comment #4) > where is the checkbox to set the assignee & QA back to default? I bet "serious" > SeaMonkey people like Serge Gautherie will even be more hurt than me by the > disparition of that one. I agree with the new behavior, that, if there was not a (SeaMonkey) bmo reorg going on, reassigning is seldom needed/done. As always, a preference could be useful when such a reorg happens, as it is currently...
A bug on hilighting has been filed by Dave Garrett: bug 452957.
The status drop down is no longer at the top of the page, so marking this bug as WFM.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.