Closed
Bug 241270
Opened 20 years ago
Closed 20 years ago
resolution select widget closes when mouse click is released - radio and select widget interaction problem (caused by <LABEL> tag)
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: asa, Assigned: justdave)
References
()
Details
Attachments
(2 files)
3.65 KB,
patch
|
myk
:
review+
|
Details | Diff | Splinter Review |
1.80 KB,
patch
|
justdave
:
review-
|
Details | Diff | Splinter Review |
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•20 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)
Comment 1•20 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?)
Comment 2•20 years ago
|
||
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•20 years ago
|
||
I see this as described on my 1.7a windows build, but again not on Linux.
Assignee | ||
Comment 4•20 years ago
|
||
(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
Comment 5•20 years ago
|
||
> I would rather remove the <select> from the label, and leave the javascript.
Makes sense to me.
Assignee | ||
Comment 6•20 years ago
|
||
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
Assignee | ||
Comment 7•20 years ago
|
||
This patch removes the select widget from the <label> block (and makes the same correction for the other "embedded" controls in the knob section).
Assignee | ||
Updated•20 years ago
|
Attachment #148220 -
Flags: review?(myk)
Comment 8•20 years ago
|
||
I strongly prefer this patch. The onchange() duplicates the function of the <label>. Let's just remove the onchange(). Patch attached.
Comment 10•20 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 11•20 years ago
|
||
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+
Assignee | ||
Comment 12•20 years ago
|
||
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-
Assignee | ||
Comment 13•20 years ago
|
||
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
Closed: 20 years ago
Flags: approval+
Resolution: --- → FIXED
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•