User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 It's weird but .clientWidth returns different widths for <select>s that are of the same width. The only difference is number of options in each of them. Testcase speaks for itself. Reproducible: Always Steps to Reproduce: Actual Results: Second <select> field has wrong .clientWidth set Expected Results: Correct .clientWidth value for second <select> element
This is an interesting case.... The spec says: the width of the padding edge (excluding the width of any rendered scrollbar between the padding edge and the border edge) We implement that by getting the frame for the element, calling GetScrollTargetFrame, then using the size of that (minus scrollbar as needed). For a combobox, the scroll target frame is the dropdown. And the two selects differ in that one has a scrollbar in the dropdown and the other does not; the scrollbar width is exactly the difference between the two numbers returned. roc, should we be skipping the GetScrollTargetFrame call for combobox here like we do for menuframes?
Or would this confuse other GetScrollFrame callers?
I think that's probably fine. None of the GetScrollFrame callers in nsGenericElement should be expecting to see the popup.
Created attachment 567481 [details] [diff] [review] Fix client* and scroll* for comboboxes to not consider the dropdown's scrollable area.
6 years ago