Last Comment Bug 320799 - .clientWidth reports different width for two <select> fields of exactly the same width if one has a scrollbar on the dropdown and the other does not
: .clientWidth reports different width for two <select> fields of exactly the s...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: CSS Object Model (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: mozilla10
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-19 04:55 PST by Donny
Modified: 2011-10-19 03:21 PDT (History)
6 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (1.66 KB, text/html)
2005-12-19 04:58 PST, Donny
no flags Details
Fix client* and scroll* for comboboxes to not consider the dropdown's scrollable area. (3.78 KB, patch)
2011-10-17 09:54 PDT, Boris Zbarsky [:bz] (still a bit busy)
roc: review+
Details | Diff | Splinter Review

Description Donny 2005-12-19 04:55:59 PST
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
Comment 1 Donny 2005-12-19 04:58:00 PST
Created attachment 206296 [details]
Testcase
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-10-14 10:31:02 PDT
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?
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-10-14 10:31:49 PDT
Or would this confuse other GetScrollFrame callers?
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-10-17 05:21:28 PDT
I think that's probably fine. None of the GetScrollFrame callers in nsGenericElement should be expecting to see the popup.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-10-17 09:54:11 PDT
Created attachment 567481 [details] [diff] [review]
Fix client* and scroll* for comboboxes to not consider the dropdown's scrollable area.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-10-18 13:57:56 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/56726a8fedea
Comment 7 Marco Bonardo [::mak] 2011-10-19 03:21:14 PDT
https://hg.mozilla.org/mozilla-central/rev/56726a8fedea

Note You need to log in before you can comment on or make changes to this bug.