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

Which version of Firefox are you running?

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

Tested and confirmed this in aurora and nightly

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.

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.

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

-moz-appearance: window; Works for me in Mac Os X, but doesn't work in Windows(XP)

Same behavior in Firefox App for Android. Mozilla/5.0 (Android; Linux armv7l; rv:10.0.2)

(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?

(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.

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?

(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.

This seems to happen not only with -moz-appearance: none; but with other values as well like -moz-appearance: textfield;

The issue related also to HTML radio buttons and checkboxes.

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.

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.

(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 :)

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!

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.

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!

I'd like to point the recent +1ers to comment 66

Did anyone at least find a workaround for this issue ? Thanks in advance.

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/

(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.

(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.

(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!)

Most excellent! I got it to work, and do recommend the .01px for text-indent. Thank you João! Peace!

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

Turns out my trick doesn't work on Firefox for Android.

Setting the text-indent to 5px gets rid of the arrow on Firefox Mobile. Who's your daddy now? :D

(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

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

The workaround is apparently working. Win8 x64 FF 28.0

Workaround is no longer working in Firefox 31 on windows 8. See screenshot of previously posted jsfiddle http://i.imgur.com/mZ7oLov.png

Workaround no longer working in FF 30.0 on OSX 10.9.2

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 95 to 98: it might be a side effect of Bug 963970. Try "-moz-appearance: treeitem" instead. It's a *hack* anyways.

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

-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.

Mounir, what do you think we should do here?

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.

@kohei, that is just using a wrapper with overflow:hidden. Not a real work-around, because the drop-down part is still full width.

@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.

@paul not sure if you checked already, but this gist is quite juicy on information regarding this issue: https://gist.github.com/joaocunha/6273016/

(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.

(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.

(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.

(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.

(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.

(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.)

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!

Is there a summary somewhere in this bug what makes the dropdown arrow hidden or styleable in other browsers (per browser)?

(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; }

airbnb.com seems affected: http://i.imgur.com/9zPGVaz.png

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.

Here is a work around that might work. You need a wrapper div for select box. http://codepen.io/anoopjohn/pen/GcJoL

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

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

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?

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

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.

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!

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.

(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?

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.

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.

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.

Fwiw, this implements the first part: remove the dropdown button for -moz-appearance:none.

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

(minor tweak to the reftest)

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

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?

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.

I 've done these with masking techniques - http://codepen.io/alico/pen/lKubw

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 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!

https://hg.mozilla.org/integration/mozilla-inbound/rev/161e4dbfff7d https://hg.mozilla.org/integration/mozilla-inbound/rev/e2d1b98b34e6

I spawned off bug 1076846 for part 2, in case we want to do that too in the future.

https://hg.mozilla.org/mozilla-central/rev/161e4dbfff7d https://hg.mozilla.org/mozilla-central/rev/e2d1b98b34e6

Great news! Looking forward to see it in a release. Thank you guys so much!

Finally! Too bad this won't be implemented until FF35 I take it? Wish it would have been included sooner.

Awesome! thanks guys!

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

(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?

(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!

(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.

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/

On FF32, that fiddle is a word that isn't clickable, Gabriel. Anyway, this has been fixed for FF35.

Seems in FF 34 on ubuntu it's broken again. I am not front-end specialist. And can provide any additional information if necessary.

(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

Thank you for the fix! It now works as it used to in my website's case.

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.

Manikanda, this is a placing to track bug/enhancements in Firefox. For support questions, please go to https://support.mozilla.org. Thanks.

7 years later, bug still there

This bug was fixed 4 years ago. Please file a new bug if there's something still not working.