User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows 98) Build Identifier: both the list selection area contain quite a few options, just having 5 item viewable is not a great for selecting items. Reproducible: Always Expected Results: Would be nice to click a button and see the list area expand over the page to allow easyer selection
nothing really to do with camino.
Assignee: pinkerton → nobody
Component: General → Layout: Form Controls
Product: Camino → Core
QA Contact: layout.form-controls
Version: unspecified → Trunk
Camino can improve the user experience by providing a button that would make that list float over the page, so that the user can make his selection, then click the ok/done/whatever button to close that floating list. this would totally be independant of the web page. This would make the life of camino much easier.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Yeah, this bug is mis-assigned. This is imo a UI issue that should be handled by various Gecko front-ends if they want. The hooks to do it are already in place -- you can resize things via the DOM. Reassigning to the front-end it started with.
Component: Layout: Form Controls → General
Product: Core → Camino
QA Contact: layout.form-controls → general
I bet someone could write a bookmarklet for this (I have one I found somewhere for live resizing of textareas); it's a neat feature, for sure, but I'm not clear on how we'd do this cleanly ourselves in a way not confusing to Camino users... pink, thoughts?
Summary: Selection list are often made too small by the web developpers, making selection hard and slow → provide mechanism for resizing <select> lists
here is the original idea i had: On the top image, the user click on the button on the lower right corner, the list view expand to use the whole height of the page, the user perform his selection and click outside the list view or on the done button in the lower right hand corner. This way we do not resize element within the page and we don't have to guess if anything in the layout will be messed up, plus we get to use the whole screen height.
Final version should have better icon, possibly a drop shadow behind the list view so that the user know it is detached from the page.
Something along the lines of the way Safari resizes TEXTAREAs is probably the best way to handle this. See also the Core bug 167951, which covers (at least) the TEXTAREA element and seems like it ought to be equally applicable to SELECT lists.
Boris says the hooks are already there (and if that's so, they may be there for <textarea>s as well, given you can use JS to resize <textarea>s); the hard thing would be getting the resize widget drawn below the bottom scroll arrow, since a) that's problematic to begin with (bug 56488) and b) we don't inject stuff into the content area, to my knowledge. Fixing a) probably requires a way to do bug 56488 comment 84 or something like that.
WONTFIX right now. If this ever becomes a common feature/feature request, or if Core adds similar UI support like bug 167951 did for textareas, we'll reconsider then.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.