User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Tested on Firefox 3.6, Firefox nightlies, Feb 25th SeaMonkey nightly. The dropdown menu portion of a select tag, normally shown when the tag is clicked, will not display if ui.use_native_popup_windows is set to true. This behaviour is not influenced by the usage of CSS to style the element. Reproducible: Always Steps to Reproduce: 1. Set ui.use_native_popup_windows to true in about:config 2. Find any page with a single-element select tag on it that offers a dropdown arrow--even the dropdowns on the bug entry page are broken 3. Attempt to open said dropdown Actual Results: The element is focused, and can be navigated with the arrow keys and by typing the first characters of the desired option, but the menu is completely absent and cannot be interacted with via the mouse. Expected Results: The dropdown menu should display. This behaviour was introduced in nightly builds far before the release of 3.6; I figured it would just go away with the efforts of countless hard-working Mozillians but it never quite did.
> I figured it would just go away You're the first to report this issue. That said, I'm not sure why you're setting this preference and what you expect it to do. This preference is only used to signal to the layout system that the widget layer will provide its own popup windows. The only widget layer that does so at the moment in Firefox is the Mac one; these are used in Camino for example. On Windows in Firefox, the only possible effect of setting this pref would be to make the dropdown not render, if it has any effect at all. In 1.9.1 the pref was ignored completely on Windows, but the relevant ifdef was removed in 1.9.2 to allow embeddings on other operating systems to provide non-built-in combobox popup UI (specifically Fennec; see bug 500208).
Thanks for the clarification. To be honest I have no idea why the preference was set (there are evidently options in about:config that mortal man was not meant to mess with) but it's good to know. Still, couldn't it be a concern for profile migration or something? Sorry for the wasted time and general newbitude.
> there are evidently options in about:config that mortal man was not > meant to mess with Yes, absolutely! There are prefs in there that are meant for debugging only (open up security holes, for example), prefs that will cause random bits of the web to not work, prefs that will slow down the browser to a crawl, and so forth. This pref could be a concern for profile migration if it ever did something in Firefox, but since it doesn't I really have no idea how this pref could get set to start with short of someone randomly poking about:config bits. It's meant to be set in the app's global preference file, not in user prefs.... And no worries about wasted time. I appreciate you filing the bug; I'd rather have bugs be filed and turn out to be non-issues than have problems go unreported.
Under KDE-4.6.x plasmanotify correctly displays download dialogs etc. when this option is enabled BUT the side effect is to loose the dropdown list functions. Enabling this has been announced by some to the KDE community (e.g. https://addons.mozilla.org/en-US/firefox/addon/plasmanotify/ last comment for Firefox 4) so more users will be experiencing it.
Argh. We should probably just make this not work as a user_pref. roc, thoughts?
We should just ignore the pref when the build doesn't have support for native select popups.
The whole point of this pref is to indicate when it does or doesn't, no? "native select popups" means something outside Gecko itself is showing the popup; there's no way to tell that from inside Gecko. Hence my suggestion that this be ignored as a user_pref.
The other option, of course, is to make this a compile-time flag and require fennec and Camino to set it.
That sounds good.
Which "that"? Compile-time flag?
Created attachment 539991 [details] [diff] [review] Get rid of the footgun ui.use_native_popup_windows preference.
Created attachment 539993 [details] [diff] [review] Camino changes to deal with this On the other hand, maybe I should leave the pref in here so that things don't break if you're not building off tip Gecko?
(In reply to comment #15) > On the other hand, maybe I should leave the pref in here so that things > don't break if you're not building off tip Gecko? Camino trunk is 1.9.2 based. With the death of embedding there is not and will never be a Camino based on a newer Gecko, so unless you plan to backport the core change to 1.9.2 it won't have any effect on Camino.
I have no plans to backport to 1.9.2. I also have no idea what the hell "death of embedding" is supposed to mean, but whatever. If you decide you want a Camino patch at some point, feel free to take one.
Comment on attachment 539991 [details] [diff] [review] Get rid of the footgun ui.use_native_popup_windows preference. r=me on the build bits.
Comment on attachment 539991 [details] [diff] [review] Get rid of the footgun ui.use_native_popup_windows preference. Review of attachment 539991 [details] [diff] [review]: -----------------------------------------------------------------
(In reply to comment #17)] > I also have no idea what the hell "death of embedding" is supposed to mean, > but whatever. https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion http://caminobrowser.org/blog/2011/ The short version is that it's no longer necessary to let us know about Camino-breaking changes on trunk. We certainly appreciate that you've always done so in the past though :)
> http://caminobrowser.org/blog/2011/ You totally misread Benjamin's post. Camino just uses nsIWebBrowser, last I checked. e10s is also built around nsIWebBrowser. So nsIWebBrowser is not going anywhere. In fact, it'll be better-maintained than it ever as been (we've fixed a bunch of bugs in it as part of e10s work). What's being removed are shim embedding APIs like gtkmozembed that tried to hide the "XPCOM stuff"... but Camino isn't using those anyway. All of which is off topic for this bug, I guess. Do feel free to mail me personally if you have any questions. But the short story is that just about every factual statement in your blog post is wrong.
attachment 539991 [details] [diff] [review] landed on mozilla-central for Gecko 7: http://hg.mozilla.org/mozilla-central/rev/9240f01e12b6 Not resolving because I'm not sure if the Camino part still needs to land; please mark this bug fixed when appropriate.
This is fixed.