The flag requestee field is enabled all the time, even when a flag isn't being requested. It should be disabled until someone requests the flag (i.e. changes the pull-down menu to "?").
Created attachment 105706 [details] [diff] [review] patch v2: unrotted This patch is unrotted and also fixes a bug that could cause a requestee field to appear for a flag that is already in the requested state.
Comment on attachment 105706 [details] [diff] [review] patch v2: unrotted tested on landfill, with bugs in the list "loaded" with the stuff that broke it before... Excel likes it. :-) r=justdave a=justdave
Comment on attachment 105706 [details] [diff] [review] patch v2: unrotted errr.... that comment was meant for a different patch, I got my windows swapped... review on this one coming right up though...
Comment on attachment 105706 [details] [diff] [review] patch v2: unrotted OK, this works, except that on Mac, you can't tell it's disabled unless you try to click on it and the caret never shows up. This is the fault of both Moz and IE, Omniweb displays it correctly. To overcome this, I guess I would go as far as hiding/showing the entire UI... when you set it to ?, the ([_____]) appears to the right...
>To overcome this, I guess I would go as far as hiding/showing the entire UI... >when you set it to ?, the ([_____]) appears to the right... The problem with this is that it's bad form to hide UI elements, which is why the disabled state exists in the first place: it makes it possible for users to see all possible options while preventing them from manipulating the ones that don't make sense in the given state. It's unfortunate some browsers have a buggy implementation of the feature, and I'm open to workarounds, but hiding the element is not the solution. The other problem with hiding the element is that it makes a generally requestable flag (one that can be set to "?" but not requested of a specific user) look like a specifically requestable flag. Note that we also use the disabled state on the "create attachment" page without problems. I think the best solution to this problem is to check in the current patch and file bugs/register complaints against the buggy browsers; and then, if we can't get traction on the problems within a reasonable time period, use CSS to style the element ourselves when it is in the disabled state.
Comment on attachment 105706 [details] [diff] [review] patch v2: unrotted agreed. reversing my review.
Checking in template/en/default/flag/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/flag/list.html.tmpl,v <-- list.html.tmpl new revision: 1.5; previous revision: 1.4 done
I noticed the same problems with Moz on Linux and even IE on windows... empty disabled text boxes just don't /look/ disabled. You could probably use .css to give them a gray background or something. Another possible solution (although it would look funny and I've never seen it done before) is to set the text in the textbox to read "Disabled" (or something) and then disabling the box. On every browser I've noticed this on, the text looks noticably different in the disabled state, even if the box itself doesn't.
Created attachment 105823 [details] Screenshot of problem When both "specifically requestable" and "multiplicable" are checked, then the disable works wrong - it disables the first item, not the last. check the screenshot.