resolution select widget closes when mouse click is released - radio and select widget interaction problem (caused by <LABEL> tag)

RESOLVED FIXED in Bugzilla 2.18

Status

()

Bugzilla
Creating/Changing Bugs
RESOLVED FIXED
14 years ago
5 years ago

People

(Reporter: asa, Assigned: justdave)

Tracking

unspecified
Bugzilla 2.18
x86
All
Bug Flags:
approval +
blocking2.18 +

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
The HTML select widget for resolving a bug in show_bug.cgi triggers some
javascript which selects the radio button. This has gone wonky on the bugzilla
tip installation at landfill.

To reproduce, just load up an open bug and click on the resolve bug select
widget. Notice that a click and release opens and closes the select instead of
opening and leaving it open. 

I suspect that whatever javascript that's activating the radio button associated
with resolving bugs is also shifting focus to that radio button and so closing
the select widget. 

This is not a problem at b.m.o. 

I've tested on current Mac and Windows Mozilla and Firefox builds and see the
brokenness there. It seems to work as expected in Safari 1.2.1 and winIE6 so
this could be a bug newly exposed in Mozilla.
(Reporter)

Updated

14 years ago

Updated

14 years ago
Depends on: 14887

Updated

14 years ago
Summary: resolution select widget closes when mouse click is released - radio and select widget interaction problem → resolution select widget closes when mouse click is released - radio and select widget interaction problem (caused by <LABEL> tag)

Updated

14 years ago
Flags: blocking2.18?
Whiteboard: suggestion: back out bug 14887

Comment 1

14 years ago
I see the problem.  Doesn't trigger locally because we have that javascript
patched out.  The solution is probably to remove the JS, since it duplicates the
functionality of the <label> tag anyway.  A workaround might be to move the
various form widgets outside of the <label>, but that makes the <label> fairly
useless.  I'll investigate.

(PS This seems like a browser bug.  What's the bugzilla policy on working around
browser bugs?)
I can't reproduce this on either the data: url or the landfill page with a
current Linux trunk build of Mozilla.  I click and release on the select, it
drops down and stays that way.

Comment 3

14 years ago
I see this as described on my 1.7a windows build, but again not on Linux.
(In reply to comment #1)
> The solution is probably to remove the JS, since it duplicates the
> functionality of the <label> tag anyway.

I would rather remove the <select> from the label, and leave the javascript. 
The javascript works on browsers that don't support <label>, so by removing it,
you'd be causing a regression for folks using such browsers.  Yes, it performs
the same function, but having the label just around the text should handle the
rest without breaking backward compatibility with the older browsers.
Whiteboard: suggestion: back out bug 14887
> I would rather remove the <select> from the label, and leave the javascript.

Makes sense to me.
Moving this to block 2.18.  This makes it almost utterly useless on the browsers
it triggers under.  Taking... I have a patch.
Assignee: myk → justdave
Flags: blocking2.18? → blocking2.18+
Target Milestone: --- → Bugzilla 2.18
Created attachment 148220 [details] [diff] [review]
Patch v1

This patch removes the select widget from the <label> block (and makes the same
correction for the other "embedded" controls in the knob section).
Attachment #148220 - Flags: review?(myk)

Comment 8

14 years ago
Created attachment 148222 [details] [diff] [review]
Removes onChange() handlers from contents of <label>

I strongly prefer this patch.  The onchange() duplicates the function of the
<label>.  Let's just remove the onchange().  Patch attached.
I'd rather not do that, for the reasons stated in comment 4.

Comment 10

14 years ago
What are these browsers that support onchange but not label?  It seems to work
fine in the important ones like IE 6, IE 5 and Moz.  Didn't check Opera.

I'm in favor of the <label> just because it improves the sematics of the markup,
and simplifies things for people who run without JS (me, in other words).
Comment on attachment 148220 [details] [diff] [review]
Patch v1

The label solution is scary since its event fires onclick, not onchange. 
That's fine for non-form fields, but form fields should use JavaScript.

This looks good. r=myk
Attachment #148220 - Flags: review?(myk) → review+
Comment on attachment 148222 [details] [diff] [review]
Removes onChange() handlers from contents of <label>

I was actually kind of ambivalent about this, because <label> *does* look
cleaner, and NS4 and the like is the only things we'd break.  However, I tested
this patch, and it doesn't make the problem go away.  Trying to choose
something in any of the widgets inside the labels still deselects the widget as
soon as you let go, even without the javascript.  I think this is because of
what Myk pointed out...  <label> fires on 'onclick' instead of 'onchange', and
'onclick' is most definitely NOT what we want here.
Attachment #148222 - Flags: review-
Checking in template/en/default/bug/knob.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/knob.html.tmpl,v  <--
 knob.html.tmpl
new revision: 1.5; previous revision: 1.4
done
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Flags: approval+
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.