Open Bug 545685 Opened 11 years ago Updated 3 years ago

Borders of <select> drop down are incorrectly rendered (missing or too thick) in different situations

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: hello, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(5 files)

User-Agent:       Opera/9.80 (Windows NT 5.2; U; en) Presto/2.2.15 Version/10.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)

See the attached screenshot and test case HTML.

I'm using system defaults for the test case. If at least one of the styles (width or parent margin) are removed - the border is drawn.

It seems that this is due to some rounding error, because I'm defining the sizes in ems - I don't think it happens when integer px values are used.

On the website I'm working on, there are more such cases - it only happens on certain combinations. The only viable workaround is to use px instead of em.

Reproducible: Always

Steps to Reproduce:
Test case attached.
Actual Results:  
The right border does not appear, when the select is expanded (see the screenshot - it shows the incorrect and correct versions).


I think that these bugs are related:
https://bugzilla.mozilla.org/show_bug.cgi?id=492718
https://bugzilla.mozilla.org/show_bug.cgi?id=406499

The bug is also present in Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.12) Gecko/2009070611 Firefox/3.0.12 (.NET CLR 3.5.30729) for the same file.
Attached file Test case (Win)
Attached image Screenshot (Win)
Attached file Testcase (Mac)
The same can be witnessed on Mac, if the border: 1px solid; is set and width is adjusted.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Also reproducible on 3.6

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Version: unspecified → 3.6 Branch
I can indeed reproduce this with Firefox 3.6 but it is fixed on trunk:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
I see this with SeaMonkey 2.1 Beta 1
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Version: 3.6 Branch → unspecified
Keywords: testcase
Attached image issue in XUL
Confirming on websites but it happens also in XUL in 4.0b9pre20110110
I can confirm that this also happens on Firefox 36.0a1 (2014-11-27) + Win7 64-bit.

Sebastian
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Server 2003 → Windows 7
Hardware: x86 → x86_64
Version: unspecified → Trunk
See Also: → 527676
I can confirm that this also happens on Firefox 37.0.1 + Win7 64-bit.

Antonio
Duplicate of this bug: 1010703
See Also: → 429302
Duplicate of this bug: 527676
Duplicate of this bug: 994923
Duplicate of this bug: 924068
Severity: trivial → normal
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: <select> right border not drawn upon certain non-integer width/parent margin combinations → Borders of <select> drop down are incorrectly rendered (missing or too thick) in different situations
Duplicate of this bug: 492718
URL: 402625
See Also: 527676
From the duplicate bug reports this happens:
- independently from HWA being enabled
- on different OSs (confirmed on Windows and OS X)
- on different borders

and is related to the drop-down list not being rendered using the native appearance (bug 402625).

Sebastian
URL: 402625
See Also: → 402625
Blocks: 1230801
On Windows 10 I cannot reproduce this issue anymore. Is that still the case on other OSs?

Sebastian
Flags: needinfo?(mozilla)
Flags: needinfo?(hello)
The related Bootstrap issue was https://github.com/twbs/bootstrap/issues/20147 . Affected OS(es) unclear.
Unfortunately there was no feedback from the initial reporter. Reading through the comments again I saw that at least Windows 7 is affected. Anybody able to clarify whether current macOS versions are affected?

Sebastian
Flags: needinfo?(mozilla)
Flags: needinfo?(hello)
You need to log in before you can comment on or make changes to this bug.