flag requestee field should be disabled unless flag is requested

RESOLVED FIXED in Bugzilla 2.18

Status

()

Bugzilla
User Interface
RESOLVED FIXED
15 years ago
5 years ago

People

(Reporter: myk, Assigned: myk)

Tracking

unspecified
Bugzilla 2.18

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

15 years ago
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 "?").
(Assignee)

Comment 1

15 years ago
Created attachment 105519 [details] [diff] [review]
patch v1: implements feature
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
Attachment #105519 - Flags: review+
(Assignee)

Comment 3

15 years ago
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.
Attachment #105519 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Blocks: 179176
(Assignee)

Updated

15 years ago
Attachment #105706 - Flags: review?
(Assignee)

Updated

15 years ago
Attachment #105706 - Flags: review?
(Assignee)

Updated

15 years ago
Attachment #105706 - Flags: review?
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
Attachment #105706 - Flags: review? → review+
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...
Attachment #105706 - Flags: review+ → review?
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...
Attachment #105706 - Flags: review? → review-
(Assignee)

Comment 7

15 years ago
>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.
Attachment #105706 - Flags: review- → review+
(Assignee)

Comment 9

15 years ago
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
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 10

15 years ago
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

15 years ago
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.
Target Milestone: --- → Bugzilla 2.18
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.