Right now you can't click "Submit Bug" on enter_bug.cgi if you have the Summary field focused. The solution is to implement a slight delay on the duplicates query.
Created attachment 456192 [details] [diff] [review] v1 Okay, this changes the datatable creation to happen on a keyup handler with a slight delay. This makes the datatable a bit more "responsive" in most people's cases (unless you type inhumanly fast--which I do, but I can live with it) and eliminates the "moving button" problem. It does introduce a minor "moving description box" problem, but in most people's cases, the table will probably appear before they can go to click on the box.
Comment on attachment 456192 [details] [diff] [review] v1 Keeping track of this bug.
Comment on attachment 456192 [details] [diff] [review] v1 It works! I couldn't hit the Submit button before the table shows up :)! Maybe I need more training :). Also, as I mentioned, we could have the button 'Submit Bug' disabled until the Duplicates loads.
I just thought about it a bit, and my only concern about disabling the Submit button is that if the event doesn't complete for some reason, the Submit button will become permanently disabled, and I don't want a failure in the dup-checking code to mean that the user can't submit their bug at all.
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/ modified js/bug.js Committed revision 7385. Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/4.0/ modified js/bug.js Committed revision 7333.
Sorry I didn't speak up earlier, I think the better fix for this is actually to display some text to the user saying "N possible duplicates found" (where N is a number) or just "possible duplicates found" and when they click on the link showing the table, maybe outlining the summary box in a yellow border or something? I'm thinking that it should feel like a flavor of validation. This relies less on timeouts and more on users choosing to see more information which i tend to prefer. We might also want to show something next to the save button if we think people will skip over it, but i don't think they will. I recommend reopening this bug and reverting the timeout solution for the link solution.
In fact the an unexpected table being displayed in the middle is not the best UI design. It bothers the user every time he is filing a bug. I think the solution proposed above is the right way to go. Thanks pyrzak!
(In reply to comment #6) > Sorry I didn't speak up earlier, I think the better fix for this is actually to > display some text to the user saying "N possible duplicates found" (where N is > a number) or just "possible duplicates found" and when they click on the link > showing the table, maybe outlining the summary box in a yellow border or > something? I'm thinking that it should feel like a flavor of validation. Well, I don't think that would actually be effective, because we're trying to catch users who are already inattentive--they didn't read the documentation saying that they should search for duplicates first, because here they are on the enter_bug page filing a duplicate. If a link pops up that they have to take some action on just to know what it is, they're most likely not even going to do it. Instead, I think a better solution is to modify the UI so that it works more like the workflow for filing a bug in Launchpad. At first, when you go to do the enter_bug page, the only thing displayed is the Summary field. Then once you enter a Summary, you have the option of either CC'ing yourself on a duplicate or continuing to file a bug. For us, in the "continue to file a bug" case we would just make the rest of the form appear with JS. For advanced users, we should probably get some feedback and see how they'd like the enter_bug form to work. (That is, perhaps a checkbox that says "skip this step in the future" or some other wording.) FWIW, I've filed several bugs lately using the new system and even though I thought I'd be annoyed by the dup table, it's actually been not annoying at all, to me personally, yet.
At least, it should be optional. It should have a parameter to disable the feature. Shouldn't it?
(In reply to comment #9) > At least, it should be optional. It should have a parameter to disable the > feature. Shouldn't it? There are probably going to be some installations that don't need it, but I'm really not sure of what the general desires will be. I'm hoping that it's something we can get feedback on from a development release.