Last Comment Bug 649849 - Make -moz-appearance:none on a combobox remove the dropdown button
: Make -moz-appearance:none on a combobox remove the dropdown button
Status: RESOLVED FIXED
: dev-doc-needed
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: -- normal with 222 votes (vote)
: mozilla35
Assigned To: Mats Palmgren (:mats)
:
Mentors:
: 674035 1007782 1024310 1029321 (view as bug list)
Depends on: 1102063
Blocks: 1076846
  Show dependency treegraph
 
Reported: 2011-04-13 16:24 PDT by Gordon Mei
Modified: 2015-09-24 10:20 PDT (History)
149 users (show)
mats: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
-
affected
-
affected
affected


Attachments
testcase (639 bytes, text/html)
2011-07-22 10:59 PDT, Mounir Lamouri (:mounir)
no flags Details
test (2.59 KB, patch)
2014-07-27 15:06 PDT, Tom Schuster [:evilpie]
no flags Details | Diff | Review
part 1, Make -moz-appearance:none on a combobox remove the dropdown button (8.15 KB, patch)
2014-08-21 16:21 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Review
part 2, mplement ::-moz-select-button pseudo for styling the combobox dropdown button (12.31 KB, patch)
2014-08-21 16:32 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Review
part 2, Implement ::-moz-select-button pseudo for styling the combobox dropdown button (12.34 KB, patch)
2014-08-22 09:11 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Review
part 1, Make -moz-appearance:none on a combobox remove the dropdown button (8.15 KB, patch)
2014-09-02 14:27 PDT, Mats Palmgren (:mats)
roc: review+
Details | Diff | Review
part 1b, Remove the default -moz-appearance:none for <select> in Fennec theme. (3.91 KB, patch)
2014-09-27 16:15 PDT, Mats Palmgren (:mats)
wjohnston2000: review+
Details | Diff | Review

Description Gordon Mei 2011-04-13 16:24:45 PDT
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.29 (KHTML, like Gecko) Chrome/12.0.733.0 Safari/534.29
Build Identifier: 

Using -moz-appearance: none, I'd expect the styling to be removed such that it's not associated with any input element visually, just as -webkit-appearance: none does.

In this case, the <select> input still shows the dropdown arrow on the right side, whereas in Webkit-based browsers, they do not.

As an example of the contrast:
http://junecloud.com/images/twitter/moz-appearance.png

Reproducible: Always
Comment 1 Tyler Downer [:Tyler] 2011-05-14 21:44:39 PDT
Which version of Firefox are you running?
Comment 2 Pedro Alves 2011-06-03 09:35:05 PDT
Bumped into this one too.

Using firefox 4.0.1.

Here's the url to test: http://jsfiddle.net/vFpmu/1/

Screenshot: http://screencast.com/t/DznWh0ubfw

I tested this on windows, mac and linux
Comment 3 Pedro Alves 2011-06-03 14:32:40 PDT
Tested and confirmed this in aurora and nightly
Comment 4 Mounir Lamouri (:mounir) 2011-07-22 10:46:02 PDT
I think our behavior would be better if we had a pseudo-element to select the button so the authors would be able to style it.
Comment 5 Mounir Lamouri (:mounir) 2011-07-22 10:59:45 PDT
Created attachment 547748 [details]
testcase

The reason I like our behavior is that setting a CSS property to have us revert to the default rendering is exactly like reverting to the default rendering and setting this CSS property. Though, we should let authors style everything here, otherwise, it's quite useless.
Comment 6 Sean Neilan 2011-07-25 12:51:41 PDT Comment hidden (obsolete)
Comment 7 Mounir Lamouri (:mounir) 2011-07-25 13:06:22 PDT Comment hidden (obsolete)
Comment 8 Sean Neilan 2011-07-25 13:10:20 PDT Comment hidden (obsolete)
Comment 9 Sean Neilan 2011-07-25 13:22:28 PDT Comment hidden (obsolete)
Comment 10 Mounir Lamouri (:mounir) 2011-07-25 13:33:06 PDT
*** Bug 674035 has been marked as a duplicate of this bug. ***
Comment 11 Sean Neilan 2011-07-25 13:39:09 PDT Comment hidden (obsolete)
Comment 12 Ivan C. 2011-08-14 11:11:00 PDT Comment hidden (spam)
Comment 13 Ivan C. 2011-08-14 11:12:46 PDT Comment hidden (spam)
Comment 14 Pedro Alves 2011-10-26 02:35:30 PDT Comment hidden (spam)
Comment 15 Salman Abbas 2011-11-06 16:59:02 PST Comment hidden (spam)
Comment 16 quentinuys@gmail.com 2011-12-28 00:11:21 PST Comment hidden (spam)
Comment 17 Pedro Alves 2011-12-29 12:02:06 PST
This has been around forever, and for webdevelopers its really a step back in usability. 

For simple things like having a selector on a dark background this means replacing the entire selector with divs/custom plugins, which is totally overkill and destroys mobile rendering, where native widgets come into play.


This can really seem simple requirements but makes all the diference to the end user
Comment 18 Ionel Maries 2012-01-13 18:05:56 PST Comment hidden (spam)
Comment 19 Micah Loffer 2012-01-17 14:39:53 PST Comment hidden (spam)
Comment 20 Nick 2012-02-14 13:32:18 PST Comment hidden (spam)
Comment 21 Roman 2012-02-17 00:44:12 PST
-moz-appearance: window; 
Works for me in Mac Os X, but doesn't work in Windows(XP)
Comment 22 sethhumphrey 2012-02-22 08:47:31 PST
Same behavior in Firefox App for Android.
Mozilla/5.0 (Android; Linux armv7l; rv:10.0.2)
Comment 23 Enrique Moreno Tent 2012-03-08 07:54:47 PST Comment hidden (spam)
Comment 24 Perry 2012-03-09 12:58:44 PST Comment hidden (spam)
Comment 25 Speedycom 2012-03-14 13:49:12 PDT Comment hidden (spam)
Comment 26 Ivan C. 2012-03-14 14:02:38 PDT Comment hidden (spam)
Comment 27 Alex Limi (:limi) — Firefox UX Team 2012-03-20 14:29:31 PDT
(In reply to Pedro Alves from comment #17)
> For simple things like having a selector on a dark background this means
> replacing the entire selector with divs/custom plugins, which is totally
> overkill and destroys mobile rendering, where native widgets come into play.

Yeah, agreed. I really think we should match what WebKit does here. Mounir, I'm not sure I understand your objections to harmonizing the behaviors, can you elaborate?
Comment 28 Mounir Lamouri (:mounir) 2012-03-21 03:24:20 PDT
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #27)
> Yeah, agreed. I really think we should match what WebKit does here. Mounir,
> I'm not sure I understand your objections to harmonizing the behaviors, can
> you elaborate?

I do not think I expressed a strong opinion against Webkit's and Presto's behavior but just that a coherent way to fix that might be to allow styling the dropdown button. Though, we could also say that a <select> is nothing else than a big <button> with a dropdown list. In that case, we could change our behavior to Webkit/Presto.

I'm planning to discuss form control styling issues next week with some DOM and Layout people. We might have a stronger opinion about what we want after that.
Comment 29 PGran 2012-05-09 10:16:13 PDT
Mounir, can you comment on the outcome of this discussion? Is there a plan for implementing the Webkit/Presto behavior or the pseudo element behavior?
Comment 30 David Calhoun 2012-06-14 10:40:16 PDT Comment hidden (spam)
Comment 31 Nick Heer 2012-06-14 10:43:10 PDT
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #28)
> I'm planning to discuss form control styling issues next week with some DOM
> and Layout people. We might have a stronger opinion about what we want after
> that.

Any updates on this? I'm currently attempting to finish something that involves a <select> box and Firefox is causing me to create some insane workarounds.
Comment 32 Adam Sentz 2012-06-18 15:07:19 PDT Comment hidden (spam)
Comment 33 rafael.g.lepper 2012-07-11 07:17:59 PDT
This seems to happen not only with -moz-appearance: none; but with other values as well like -moz-appearance: textfield;
Comment 34 Enrique Moreno Tent 2012-07-11 07:27:29 PDT Comment hidden (spam)
Comment 35 Speedycom 2012-07-11 08:17:27 PDT Comment hidden (spam)
Comment 36 Muranyi A. 2012-07-11 08:27:48 PDT Comment hidden (spam)
Comment 37 Speedycom 2012-07-11 08:29:02 PDT Comment hidden (spam)
Comment 38 Zac Parker 2012-07-24 14:23:22 PDT Comment hidden (spam)
Comment 39 silversens 2012-08-21 09:41:34 PDT Comment hidden (spam)
Comment 40 Jeff Green 2012-08-21 10:23:04 PDT Comment hidden (spam)
Comment 41 persona 2012-09-11 18:31:09 PDT Comment hidden (spam)
Comment 42 Barth 2012-09-18 09:24:12 PDT Comment hidden (spam)
Comment 43 Barth 2012-09-18 09:28:24 PDT Comment hidden (spam)
Comment 44 r.schopmeijer 2012-10-09 02:09:54 PDT Comment hidden (spam)
Comment 45 Priscila 2012-10-10 10:19:29 PDT Comment hidden (spam)
Comment 46 Voda 2012-10-11 07:00:52 PDT Comment hidden (spam)
Comment 47 Binyamin 2012-10-23 10:56:10 PDT
The issue related also to HTML radio buttons and checkboxes.
Comment 48 jarod 2012-10-23 14:26:39 PDT Comment hidden (spam)
Comment 49 Barth 2012-10-24 05:48:42 PDT Comment hidden (spam)
Comment 50 Barth 2012-10-24 05:50:38 PDT Comment hidden (spam)
Comment 51 Voda 2012-10-24 06:55:02 PDT Comment hidden (spam)
Comment 52 Anthony Ricaud (:rik) 2012-10-24 08:40:29 PDT
Please, don't spam this bug. Most of the comments are not helping to get this bug fixed. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.

Thank you.
Comment 53 Perry 2012-10-24 08:52:18 PDT Comment hidden (spam)
Comment 54 Enrique Moreno Tent 2012-10-24 08:57:21 PDT Comment hidden (spam)
Comment 55 Binyamin 2012-10-24 10:13:22 PDT Comment hidden (spam)
Comment 56 Dmitry 2012-10-29 09:41:29 PDT Comment hidden (spam)
Comment 57 gene 2012-12-03 07:22:23 PST Comment hidden (spam)
Comment 58 Jason Han 2012-12-14 08:29:55 PST Comment hidden (spam)
Comment 59 Wraithan (Chris McDonald) [:wraithan] 2012-12-14 11:54:48 PST
I am not on any of the teams that work on Firefox, I am a webdev for Mozilla. I brought this up in a channel looking to see if I could get a status update on this.

My reply has been the following: 

First, because the bug has a lot of hostile spam in it, it creates a hostile workplace for anyone who gets assigned to this. 

Secondly, the person who has the ability to do this (which includes rewriting <select>) has been allocated to another project (b2g) for the time being and wont have time until that project get nearer to completion.

Third, even when that person has the time again, there is no guarantee that this will be a priority because, despite webkit having this, it breaks the spec for how <select> is supposed to work (This is what I was told, I do not personally know the spec)

This is an unofficial update, but it is better than silence so here you go.
Comment 60 Michael JasonSmith 2013-01-22 15:46:43 PST
(In reply to Wraithan from comment #59)

Thanks for the update. I appreciate that even a minor change can require a lot of work if the code was not designed to do a particular thing. It is even harder if the "right" thing to do is not crystal clear. I also appreciate that it is far easier to spam this bug than to fix the issue, and that people with skills, knowledge and ability are hard to come by (unlike trolls).

As many have pointed out, it is a tiny issue, and people who really do care do have options. For me it was nice to know that the problem on my page was not my fault :)
Comment 61 Enrique Moreno Tent 2013-01-22 16:36:50 PST Comment hidden (spam)
Comment 62 Binyamin 2013-01-22 22:55:58 PST Comment hidden (off-topic)
Comment 63 Morris 2013-02-27 15:48:09 PST
FYI: This is acheivable in IE10 using the -ms-expand pseudo-element:

select[disabled='disabled']::-ms-expand {
	visibility: hidden;
}

And to change the text color in IE10:

select[disabled='disabled']::-ms-value {
	color: #000;
}

PS: What a shame to find nasty people in the bug forums.

Mozilla, you guys rock!
Comment 64 rick.pickett 2013-03-21 15:01:26 PDT Comment hidden (spam)
Comment 65 Narender 2013-03-22 03:16:00 PDT Comment hidden (spam)
Comment 66 Wraithan (Chris McDonald) [:wraithan] 2013-03-22 13:20:04 PDT
rick.pickett: Comments stating it is taking too long, comments that are simply 'bumps' do not actually do anything. This isn't a forum. This is a desired feature and we get that (as a webdev I've hit this bug in my own work) but noise and static wont get this done any faster.

Narender: Currently not slated for a particular version. Target Milestone will change when it is slated for a version.

There is a limited number of engineers available, and an even smaller number of engineeers who will be effective in this area of the code. Priorities are not as simple as this is higher than that, it also has to do with who knows the code in a given area.

I encourage people who feel passionately about this bug to get involved and write code.
Comment 67 rick.pickett 2013-03-22 13:24:37 PDT
Thanks for the feedback Wraithan, just wanted to add my support for it to be addressed. If I could write code, I would help out. Thanks for the work!
Comment 68 Raul Fenossi 2013-04-17 11:40:23 PDT Comment hidden (spam)
Comment 69 3G 2013-05-10 13:36:48 PDT Comment hidden (spam)
Comment 70 Daniel Golden 2013-06-03 13:30:04 PDT Comment hidden (spam)
Comment 71 Flakerim 2013-06-05 03:31:49 PDT Comment hidden (spam)
Comment 72 Jordan Leven 2013-06-05 16:39:45 PDT Comment hidden (spam)
Comment 73 Wraithan (Chris McDonald) [:wraithan] 2013-06-05 17:58:56 PDT
I'd like to point the recent +1ers to comment 66
Comment 74 pd 2013-06-06 17:04:02 PDT Comment hidden (spam)
Comment 75 Wraithan (Chris McDonald) [:wraithan] 2013-06-06 17:24:33 PDT Comment hidden (spam)
Comment 76 pd 2013-06-06 17:55:11 PDT Comment hidden (spam)
Comment 77 Binyamin 2013-06-08 22:29:33 PDT Comment hidden (spam)
Comment 78 Hesham Hamdy Massoud 2013-07-04 18:10:53 PDT
Did anyone at least find a workaround for this issue ? Thanks in advance.
Comment 79 Caspar Hübinger 2013-07-14 07:04:04 PDT Comment hidden (obsolete)
Comment 80 teodorescu.serban 2013-07-29 10:27:23 PDT Comment hidden (spam)
Comment 81 sethhumphrey 2013-07-30 14:21:56 PDT Comment hidden (spam)
Comment 82 Nelson Pecora 2013-08-14 08:57:50 PDT Comment hidden (obsolete)
Comment 83 Caspar Hübinger 2013-08-14 10:17:04 PDT Comment hidden (obsolete)
Comment 84 João Cunha 2013-08-19 08:24:37 PDT
Just figured out a way to remove the select arrow from Firefox. The trick is to use a mix of -prefix-appearance, text-indent and text-overflow.

select {
    -webkit-appearance: none;
    -moz-appearance: none;
    text-indent: 1px;
    text-overflow: '';
}

It's pure CSS and requires no extra markup. Tested on Ubuntu and Linux, latest versions.

Live example: http://jsfiddle.net/4WVZW/
Comment 85 Binyamin 2013-08-19 11:39:31 PDT
(In reply to João Cunha from comment #84)
>     text-indent: 1px;

João, use better "text-indent: 0.01px;" to minimize the UI changes.
Comment 86 João Cunha 2013-08-19 11:42:56 PDT
(In reply to Binyamin from comment #85)
> (In reply to João Cunha from comment #84)
> >     text-indent: 1px;
> 
> João, use better "text-indent: 0.01px;" to minimize the UI changes.

Agreed! Pretty neat solution, though, isn't it? Just tested on Windows 8 and it works just as fine.
Comment 87 Ricardo Fuhrmann 2013-08-19 11:57:16 PDT
(In reply to João Cunha from comment #84)
> Just figured out a way to remove the select arrow from Firefox. The trick is
> to use a mix of -prefix-appearance, text-indent and text-overflow.
> 
> select {
>     -webkit-appearance: none;
>     -moz-appearance: none;
>     text-indent: 1px;
>     text-overflow: '';
> }
> 
> It's pure CSS and requires no extra markup. Tested on Ubuntu and Linux,
> latest versions.
> 
> Live example: http://jsfiddle.net/4WVZW/


This is amazing! Nice solution. Thank you, João! (Valeu!)
Comment 88 rick.pickett 2013-08-19 12:01:52 PDT
Most excellent! I got it to work, and do recommend the .01px for text-indent.

Thank you João! Peace!
Comment 89 João Cunha 2013-08-21 10:57:36 PDT
I'm glad you guys liked my approach.

I've created a gist for the fix so everybody can jump in and collaborate: https://gist.github.com/joaocunha/6273016
Comment 90 João Cunha 2013-09-02 03:02:23 PDT
Turns out my trick doesn't work on Firefox for Android.
Comment 91 João Cunha 2013-09-02 04:24:38 PDT
Setting the text-indent to 5px gets rid of the arrow on Firefox Mobile. Who's your daddy now? :D
Comment 92 Noelia 2014-02-18 08:44:01 PST
(In reply to João Cunha from comment #84)
> Just figured out a way to remove the select arrow from Firefox. The trick is
> to use a mix of -prefix-appearance, text-indent and text-overflow.
> 
> select {
>     -webkit-appearance: none;
>     -moz-appearance: none;
>     text-indent: 1px;
>     text-overflow: '';
> }
> 
> It's pure CSS and requires no extra markup. Tested on Ubuntu and Linux,
> latest versions.
> 
> Live example: http://jsfiddle.net/4WVZW/

AWESOMENESS!!!! Thank you very much :D :D :D
Comment 93 Soelen 2014-04-09 18:40:02 PDT
Since a few nightly updates the workaround doesn't work anymore yet the bug still exists

Windows 7 64bit
31.0a1 (2014-04-08) Firefox Nightly 64bit version
Comment 94 flowtex 2014-04-13 14:23:10 PDT
The workaround is apparently working.
Win8 x64 FF 28.0
Comment 95 emitstop 2014-04-22 10:54:08 PDT
Workaround is no longer working in Firefox 31 on windows 8. See screenshot of previously posted jsfiddle http://i.imgur.com/mZ7oLov.png
Comment 96 Alice0775 White 2014-05-08 11:27:38 PDT
*** Bug 1007782 has been marked as a duplicate of this bug. ***
Comment 97 David Vespoli 2014-05-15 04:35:12 PDT
Workaround no longer working in FF 30.0 on OSX 10.9.2
Comment 98 Dan 2014-05-17 11:19:45 PDT
Does anyone know where the default drop down arrow image is located within the FF application (on OS X)?  Would be nice to simply replace it - if that is even possible - until this issue is resolved.
Comment 99 Kohei Yoshino [:kohei] 2014-05-17 19:28:11 PDT
Comment 95 to 98: it might be a side effect of Bug 963970. Try "-moz-appearance: treeitem" instead. It's a *hack* anyways.
Comment 100 mc 2014-05-21 15:37:56 PDT
Anyone have any ideas, I've tried adding -moz-appearance: none; to select and it's still showing up FF 30.0 on OSX 10.9.3
Comment 101 mc 2014-05-21 15:38:41 PDT Comment hidden (spam)
Comment 102 João Cunha 2014-05-21 15:46:10 PDT Comment hidden (me-too)
Comment 103 emitstop 2014-05-21 16:35:04 PDT Comment hidden (me-too)
Comment 104 mc 2014-05-21 21:27:43 PDT Comment hidden (me-too)
Comment 105 Ben Saufley 2014-05-30 08:16:24 PDT
-moz-appearance: treeitem removes other relevant styling. -moz-appearance: none does not work. I don't so much mind not being able to *style* the arrow, as not being able to *remove* it.
Comment 106 Paul Rouget [:paul] 2014-05-30 08:33:03 PDT
Mounir, what do you think we should do here?
Comment 107 Kohei Yoshino [:kohei] 2014-06-03 07:18:06 PDT
For people who are looking for a workaround for this: See <select> on the footer of https://mozillians.org/, it hides the dropdown arrow with an extra width.
Comment 108 Andy Mercer 2014-06-03 07:22:27 PDT
@kohei, that is just using a wrapper with overflow:hidden. Not a real work-around, because the drop-down part is still full width.
Comment 109 João Cunha 2014-06-03 07:39:56 PDT
@kohei, there are several techniques for styling a select element, the most common one being to make it translucent and absolute positioned on top of it's wrapper label - then you style the label itself.
Comment 110 João Cunha 2014-06-03 07:40:26 PDT
@paul not sure if you checked already, but this gist is quite juicy on information regarding this issue: https://gist.github.com/joaocunha/6273016/
Comment 111 Mounir Lamouri (:mounir) 2014-06-07 06:00:17 PDT
(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #106)
> Mounir, what do you think we should do here?

Ideally? Allow styling the arrow via a pseudo-element and probably get rid of it in some situations. We fallback to a non-native style in a few situations: when some CSS properties are set and when moz-appearance: none is used. Maybe we should keep the arrow in the former situation and remove it in the later. Though, it might break some content so it's not as simple as just doing it.
Comment 112 Ricardo Maçãs [:Ricmacas] 2014-06-11 01:55:57 PDT
(In reply to Mounir Lamouri (:mounir) from comment #111)
> it in the later. Though, it might break some content so it's not as simple
> as just doing it.

I'd say that it is probably breaking more websites now, given that Firefox 30 was released changing the rendering of the <select> hack used by some webdevs in the previous versions. I originally found how to style the dropdown menu with a simple Google search and it already included the Firefox hack - plenty of menus don't rely on this, but many already do - without warning of this problem. But then again, it's on MDC, I could have checked this.

However, note that webkit browsers already remove the arrow with -webkit-appearance:none, as Firefox used to do with the hack, so I'd guess it'd be more consistent if Firefox did this by default as well.

All in all, I'd say it's worse to keep it as it is.
Comment 113 mllegeorgesand 2014-06-11 05:14:13 PDT Comment hidden (me-too)
Comment 114 Andy Mercer 2014-06-11 08:25:59 PDT
(In reply to mllegeorgesand from comment #113)
> Please have -webkit-appearance:none remove the arrow.
> I have been forced to use a solution that involves no JavaScript, and no
> wrapping of the select element in another element. This has worked well,
> although it's been a hack: http://stackoverflow.com/q/23920990/1596087 Time
> to get rid of hacks! At least for Firefox.

It would be -moz-appearance:none, or appearance none. Firefox doesn't support custom webkit properties, because they aren't real. They are just temporary rules that work in Webkit browsers to test our the real CSS rules.
Comment 115 Kohei Yoshino [:kohei] 2014-06-11 23:24:00 PDT
*** Bug 1024310 has been marked as a duplicate of this bug. ***
Comment 116 Kostas 2014-06-12 06:03:19 PDT Comment hidden (me-too)
Comment 117 Kohei Yoshino [:kohei] 2014-06-12 06:17:25 PDT
(In reply to Kostas from comment #116)
> Can someone give us a clear answer or solution on this ?
> How can we now replace the default select button with a custom graphic ?

See the footer of https://mozillians.org/en-US/ for example. There should be a language selector with a custom arrow icon.
Comment 118 Andy Mercer 2014-06-12 06:33:58 PDT
(In reply to Kostas from comment #116)
> Can someone give us a clear answer or solution on this ?
> How can we now replace the default select button with a custom graphic ?

Bugzilla is a bug track for Firefox. It is a place for FF developers to track bugs, track changes, submit patches, etc. For support for web development, a better place to ask is StackOverflow (http://stackoverflow.com/q/23920990/2111901), as mllegeorgesand mentioned in Comment 113. Part of the reason this is taking so long is that we flooded this thread. It would be wonderful to get some movement on it, but everyone needs to understand that there are a limited number of developers who can handle a change like this inside Firefox (or Gecko?). Basically, if you want to submit a patch, comment here. If you want to ask about status, ask about work arounds, etc ... don't comment here.
Comment 119 emitstop 2014-06-12 18:17:21 PDT Comment hidden (spam)
Comment 120 mc 2014-06-12 20:58:39 PDT Comment hidden (spam)
Comment 121 Andy Mercer 2014-06-13 05:40:10 PDT
(In reply to emitstop from comment #119)
> Sorry, but that is ****. People discussing the issue in this thread isn't
> going to slow down the development of Firefox... If anything it should
> highlight how large of an issue this has become because it has been
> neglected for so long. If activity on a bug thread in bugzilla results in
> the developers delaying a fix even longer, than that is a serious issue with
> the development workflow of Firefox itself. People are in here asking for
> fixes because there is hardly any information elsewhere on an issue that's
> been created by and continually neglected by the development team.
> 
> If you're saying the amount of responses in this thread is obscuring the
> relevant information then that's silly because the only relevant information
> necessary is: 'there is no way to remove the damned button.'

(In reply to mc from comment #120)
> This is not logical.  The more posts to a legitimate bug, the less likely it
> is to be fixed?  Sorry, I'm a software engineer, and the squeaky wheel
> always gets the grease.  Our jobs depend on that.  We also haven't seen any
> responses from the dev team.  Works fine in Chrome.  We'll just push our
> users that way if need be.

Go read Comment 59 and Comment 66. 

(And note, I'm not saying I think it's right (I'm not a FF dev). I'm repeating what we've already been told, that we shouldn't continue to flood this thread because past flooding caused the initial delay. To take my own advice, I'm going to abstain from further discussion here.)
Comment 122 Liz Henry (:lizzard) (needinfo? me) 2014-06-17 07:59:51 PDT
dbaron, it looks like the common workarounds to this problem no longer work. Related: bug 963970 and bug 1017864.  Is this something that your team can take a look at? Thanks!
Comment 123 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2014-06-18 15:45:28 PDT
Is there a summary somewhere in this bug what makes the dropdown arrow hidden or styleable in other browsers (per browser)?
Comment 124 Ben 2014-06-19 02:57:43 PDT Comment hidden (abusive)
Comment 125 Mathieu Gagnon 2014-06-19 06:42:48 PDT
(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #123)
> Is there a summary somewhere in this bug what makes the dropdown arrow
> hidden or styleable in other browsers (per browser)?

Chrome and webkit browsers : select { -webkit-appearance: none; }
IE : select::-ms-expand { display: none; }
Comment 126 mllegeorgesand 2014-06-19 07:19:36 PDT Comment hidden (me-too)
Comment 127 greg taff 2014-06-23 12:50:27 PDT Comment hidden (me-too)
Comment 128 :Gijs Kruitbosch 2014-06-24 03:13:37 PDT
*** Bug 1029321 has been marked as a duplicate of this bug. ***
Comment 129 Paul Rouget [:paul] 2014-06-24 03:18:20 PDT
airbnb.com seems affected: http://i.imgur.com/9zPGVaz.png
Comment 130 Curreli's 2014-06-24 10:04:32 PDT
I've spent a few hours trying every FF css hack out there, none of the old ways work any more.

html>/**/body select does target FF 3.0 (and Chrome for some reason), but this is only to style the select element, not to remove the default arrow.

One work around is to have an image using a <span><i> or what ever element you want to use next to it, then simply have it overlay the original button using negative margins or using the position styling (if the parent has a position styling as well).

Not ideal, but perfectly fine for some cases.
Comment 131 anoop_john 2014-06-24 22:46:41 PDT
Here is a work around that might work. You need a wrapper div for select box. 
http://codepen.io/anoopjohn/pen/GcJoL
Comment 132 João Cunha 2014-06-25 06:05:14 PDT
Nice finding by keksa (https://gist.github.com/joaocunha/6273016#comment-1252481). By playing with flexbox, height, absolute position and borders he was able to ditch the arrow. Not really useful to style the element but can help us preventing bugs in the future.

His codepen shows how it works (but not why!): http://codepen.io/keksa/pen/hpqyx
Comment 133 greg taff 2014-07-01 13:22:11 PDT Comment hidden (me-too)
Comment 134 João Cunha 2014-07-01 13:27:16 PDT
I shared his finding as it shows some kind of quirkness going on. As people are already reviewing the select element for a fix, it might be useful to investigate the cause of the problem. It's not supposed to be used for styling.

(In reply to greg taff from comment #133)
> i can certainly appreciate the intention, but lets stop sharing hacks, and
> work arounds in this thread - especially those which require additional
> markup, and hectic css.  These would be great for discussion of this issue
> in blogs and development forums, but they aren't an acceptable long term
> solution to this problem and just dilutes this thread.  This bug needs a
> solid long term solution.  
> 
> (In reply to João Cunha from comment #132)
> > Nice finding by keksa
> > (https://gist.github.com/joaocunha/6273016#comment-1252481). By playing with
> > flexbox, height, absolute position and borders he was able to ditch the
> > arrow. Not really useful to style the element but can help us preventing
> > bugs in the future.
> > 
> > His codepen shows how it works (but not why!):
> > http://codepen.io/keksa/pen/hpqyx
Comment 135 Curreli's 2014-07-01 14:02:11 PDT
I've wrote up a blog post about this bug, perhaps it could help some people.
It includes a summary of the bug and two workarounds, www.currelis.com/firefox-30-0-select-arrow-css-longer-works.html

I think we established that there is no perfect solution however, I would personally suggest people to simply use the default arrow, not only for firefox but other browsers as well.

I feel like this isn't a bug but more of a choice to exclude styling for the drop down arrow, and if so, do we really want to hack some browsers while using default arrows for others?
Comment 136 Guyllaume Doyer 2014-07-02 02:38:23 PDT Comment hidden (advocacy)
Comment 137 mbazaczek 2014-07-02 14:04:16 PDT Comment hidden (spam)
Comment 138 Stanislav Georgiev 2014-07-04 11:21:25 PDT Comment hidden (spam)
Comment 139 rludgero 2014-07-06 03:21:30 PDT
Hi, this is what i'm using in the current project i'm working nowadays. 
Vendor pseudo class :-moz-any() and pointer events only for mozilla because both is valid since version 3.6.

you can check this here

http://jsbin.com/pozomu/4/edit
Comment 140 alex_mayorga 2014-07-21 07:49:25 PDT Comment hidden (me-too)
Comment 141 Adam Picitelli 2014-07-22 07:50:59 PDT Comment hidden (spam)
Comment 142 Tom Schuster [:evilpie] 2014-07-27 15:06:01 PDT
Created attachment 8463169 [details] [diff] [review]
test

I tried to work on this, but sadly I wasn't able to figure out how to get the style context right. This might actually be a lot more involved, with having to replace the nsTextFrame or something like that.
Comment 143 Patrick Mead 2014-07-29 18:59:44 PDT
Just a quick note that might help whoever takes this on:

I've noticed that this bug does not occur in Responsive Design View (Ctrl + Shift + M).
When in Responsive View, any select element with a border or background set will not display any dropdown arrow. I'm not sure if this is a bug or intended functionality, but it does suggest that there might be a shortcut to fixing this bug, as it's already fixed in some cases!
Comment 144 Lawrence Mandel [:lmandel] (use needinfo) 2014-07-31 14:17:26 PDT
I had marked tracking on this to ensure that I followed up with Jet. Dropping the tracking flags now that we've had the conversation about 32 and 33.
Comment 145 Lawrence Mandel [:lmandel] (use needinfo) 2014-08-01 05:53:09 PDT
(In reply to Lawrence Mandel [:lmandel] from comment #144)
> I had marked tracking on this to ensure that I followed up with Jet.
> Dropping the tracking flags now that we've had the conversation about 32 and
> 33.

To further clarify, Jet confirmed that we are not going to be able to fix this in time for beta.

Jet - Can you comment on the feasibility of fixing this bug or some other way to support the issue reported in bug 1017864 in the Aurora 33 time frame?
Comment 146 Jet Villegas (:jet) 2014-08-13 09:11:02 PDT
Bug 1017864 has been marked fixed and no longer depends on this bug. 

Fixing this right may require a new pseudo-element for the drop-down arrow, and related multi-vendor spec work. We could also match the webkit behavior and have appearance:none hide the arrow. 

In either case, we wouldn't rush such a thing through a late Beta.
Comment 147 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2014-08-13 09:23:24 PDT
I think I'd prefer to use -moz-appearance: none as the trigger (even though that wasn't the original purpose of the 'appearance' property) given that it's a cleaner API and more closely matches WebKit, though it is a riskier approach than adding a new pseudo-element because of compatibility risk (pages that didn't intend for the dropdown to disappear ending up with no dropdown).

Switching the anonymous button to get its style from a pseudo-element is probably also an ok approach (though I'm not sure why attachment 8463169 [details] [diff] [review] plus appropriate changes to forms.css didn't work), but we'd really want to try standardizing it so we can move to getting interop between browsers.

jwatt said he'd give it a try.
Comment 148 Mats Palmgren (:mats) 2014-08-21 16:18:29 PDT
I like Mounir's idea in comment 111: make an explicit -moz-appearance:none
suppress the rendering of the dropdown button, but render it when the native
theme is inhibited by an author specified background or border.  The former
makes us compatible with WebKit for appearance:none, the latter allows
styling both the overall control and the dropdown button using a pseudo.
Comment 149 Mats Palmgren (:mats) 2014-08-21 16:21:59 PDT
Created attachment 8477055 [details] [diff] [review]
part 1, Make -moz-appearance:none on a combobox remove the dropdown button

Fwiw, this implements the first part: remove the dropdown button for
-moz-appearance:none.
Comment 150 Mats Palmgren (:mats) 2014-08-21 16:32:37 PDT
Created attachment 8477057 [details] [diff] [review]
part 2, mplement ::-moz-select-button pseudo for styling the combobox dropdown button

This builds on the patch from :evilpie - there we're a couple of things
missing: we should inhibit the native theme on the dropdown button when
a border/background is specified (using the pseudo), and a fctor tweak
because nsComboboxControlFrame implements CreateFrameFor so it goes
through CreateAnonymousFrames which doesn't pick up any style context
from that call, just a frame.  I found a comment about it here:
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp?rev=b8041e7ee525#9568
Comment 151 Mats Palmgren (:mats) 2014-08-22 09:11:24 PDT
Created attachment 8477461 [details] [diff] [review]
part 2, Implement ::-moz-select-button pseudo for styling the combobox dropdown button

(minor tweak to the reftest)
Comment 152 Mats Palmgren (:mats) 2014-09-02 14:27:21 PDT
Created attachment 8483022 [details] [diff] [review]
part 1, Make -moz-appearance:none on a combobox remove the dropdown button

I think we should do at least part 1 (see comment 148).

Part 2 only if other vendors agree and we have an unprefixed
pseudo name.

https://tbpl.mozilla.org/?tree=Try&rev=30a07e61b7ad
Comment 153 Alfonse 2014-09-15 15:15:27 PDT Comment hidden (me-too)
Comment 154 Mats Palmgren (:mats) 2014-09-21 12:57:23 PDT
I think we should land at least part 1 (see comment 148).

Part 2 only if other vendors agree and when we have an unprefixed
pseudo name.

Do you agree?
Comment 155 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2014-09-24 15:58:18 PDT
Landing part 1 sounds fine.

I have mixed feelings about landing part 2.  Nobody in the CSS Working Group right now seems interested in driving any spec work on styling form controls, so it seems unlikely that there will be any agreement on a name anytime soon.
Comment 156 thealico 2014-09-27 02:50:09 PDT
I 've done these with masking techniques - http://codepen.io/alico/pen/lKubw
Comment 157 Mats Palmgren (:mats) 2014-09-27 16:15:21 PDT
Created attachment 8496480 [details] [diff] [review]
part 1b, Remove the default -moz-appearance:none for <select> in Fennec theme.

We can't have -moz-appearance:none by default since it now suppresses
the dropdown button.  Removing this declaration for <select> seems
to work fine in my local Fennec Nightly build on a Nexus.

https://tbpl.mozilla.org/?tree=Try&rev=c4799a984f58
Comment 158 Wesley Johnston (:wesj) 2014-10-01 13:25:31 PDT
Comment on attachment 8496480 [details] [diff] [review]
part 1b, Remove the default -moz-appearance:none for <select> in Fennec theme.

Review of attachment 8496480 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for fixing this!
Comment 160 Mats Palmgren (:mats) 2014-10-02 06:23:28 PDT
I spawned off bug 1076846 for part 2, in case we want to do that too in the future.
Comment 162 martin.rasser 2014-10-02 10:39:53 PDT
Great news! Looking forward to see it in a release. Thank you guys so much!
Comment 163 Alfonse 2014-10-02 10:46:02 PDT
Finally! Too bad this won't be implemented until FF35 I take it? Wish it would have been included sooner.
Comment 164 greg taff 2014-10-02 10:55:04 PDT
Awesome!  thanks guys!
Comment 165 Jean-Yves Perrier [:teoli] 2014-10-06 23:29:34 PDT
We triaged recent bugs in need of doc (new process).
Documenting this bug means updating this page (and Fx 35 for devs): https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-appearance
Comment 166 João Cunha 2014-10-07 00:18:37 PDT
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #161)
> https://hg.mozilla.org/mozilla-central/rev/161e4dbfff7d
> https://hg.mozilla.org/mozilla-central/rev/e2d1b98b34e6

Awesome! Can we make sure this is shipped to FF mobile too in the future?
Comment 167 Adam Brunner 2014-10-07 00:21:07 PDT
(In reply to Jean-Yves Perrier [:teoli] from comment #165)
> We triaged recent bugs in need of doc (new process).
> Documenting this bug means updating this page (and Fx 35 for devs):
> https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-appearance

Where should we fill bugs with the documentation page? There is a typo "Applies t: all elements" << missing "o".

BTW, thanks guys for fixing this!
Comment 168 Jean-Yves Perrier [:teoli] 2014-10-07 05:26:32 PDT
(In reply to Adam Brunner from comment #167)
> Where should we fill bugs with the documentation page? There is a typo
> "Applies t: all elements" << missing "o".

It is wiki, so just fix a typo :-) I fixed it. Thanks for notifying it. For more complex problem https://bugzilla.mozilla.org/form.doc will file the bug at the right place.
Comment 169 Gabriel Rezende Dantas 2014-11-07 05:07:28 PST
My solution to the problem:

<div>
<select disabled>
<option>Test</option>
</select>
</div>

<style>
div{
overflow: hidden
}

select{
    position: absolute;
    width: 110%;
    border: 0;
    background: none;
    color: #000;
}
</style>

http://jsfiddle.net/orcjyuLp/
Comment 170 Andy Mercer 2014-11-07 07:40:27 PST
On FF32, that fiddle is a word that isn't clickable, Gabriel. Anyway, this has been fixed for FF35.
Comment 171 artem.loginov.pub 2014-12-16 04:01:56 PST
Seems in FF 34 on ubuntu it's broken again. I am not front-end specialist. And can provide any additional information if necessary.
Comment 172 Sebastian Zartner [:sebo] 2014-12-16 04:17:52 PST
(In reply to artem.loginov.pub from comment #171)
> Seems in FF 34 on ubuntu it's broken again. I am not front-end specialist.
> And can provide any additional information if necessary.

As the target milestone indicates the changes of this bug target Firefox 35+.

Sebastian
Comment 173 Ben 2015-02-01 22:55:35 PST
Thank you for the fix! It now works as it used to in my website's case.
Comment 174 manikanda prabu 2015-09-23 00:05:10 PDT
How can i make select box appearance as like as chrome 
i.e : when options shown border for an option box is not good to see.
Comment 175 Andy Mercer 2015-09-24 10:20:10 PDT
Manikanda, this is a placing to track bug/enhancements in Firefox. For support questions, please go to https://support.mozilla.org. Thanks.

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