178984 - flag requestee field should be disabled unless flag is requested

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

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 "?").

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: implements feature

Comment 2

[Dave Miller [:justdave]]

Comment on attachment 105519 [details] [diff] [review]
patch v1: implements feature

Thank you for making it visible by default and using javascript to hide it. :-)
 That way it's visible anyway if someone has javascript off. :)

r= justdave
a= justdave

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Attachment: 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 4

[Dave Miller [:justdave]]

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 5

[Dave Miller [: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 6

[Dave Miller [:justdave]]

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...

Comment 7

[Myk Melez [:myk] [@mykmelez]]

>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 8

[Dave Miller [:justdave]]

Comment on attachment 105706 [details] [diff] [review]
patch v2: unrotted

agreed.  reversing my review.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

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

Comment 10

[Jacob Steenhagen]

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.

Comment 11

[Toms Baugis]

Attachment: 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.