Last Comment Bug 548734 - ui.use_native_popup_windows breaks <select> dropdowns
: ui.use_native_popup_windows breaks <select> dropdowns
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla7
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
: Jet Villegas (:jet)
Mentors:
http://www.google.com/advanced_search
: 614209 662269 (view as bug list)
Depends on: 664917
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-25 22:07 PST by Hexadecima
Modified: 2011-06-22 10:37 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Get rid of the footgun ui.use_native_popup_windows preference. (7.16 KB, patch)
2011-06-16 22:41 PDT, Boris Zbarsky [:bz] (still a bit busy)
roc: review+
khuey: review+
Details | Diff | Splinter Review
Camino changes to deal with this (1.52 KB, patch)
2011-06-16 22:43 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review

Description Hexadecima 2010-02-25 22:07:37 PST
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.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2010-02-25 23:19:17 PST
> 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).
Comment 2 Hexadecima 2010-02-25 23:27:25 PST
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.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2010-02-25 23:39:31 PST
> 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.
Comment 4 Thomas Ahlblom 2011-06-06 08:20:30 PDT
*** Bug 614209 has been marked as a duplicate of this bug. ***
Comment 5 Sait Umar 2011-06-06 08:31:34 PDT
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.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-06-06 08:36:53 PDT
Argh.  We should probably just make this not work as a user_pref.  roc, thoughts?
Comment 7 (mostly gone) XtC4UaLL [:xtc4uall] 2011-06-06 10:22:25 PDT
*** Bug 662269 has been marked as a duplicate of this bug. ***
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-06-06 17:01:04 PDT
We should just ignore the pref when the build doesn't have support for native select popups.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-06-16 20:16:36 PDT
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.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2011-06-16 20:21:35 PDT
The other option, of course, is to make this a compile-time flag and require fennec and Camino to set it.
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-06-16 21:50:54 PDT
That sounds good.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-06-16 22:00:44 PDT
Which "that"?  Compile-time flag?
Comment 13 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-06-16 22:03:24 PDT
Yes.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2011-06-16 22:41:17 PDT
Created attachment 539991 [details] [diff] [review]
Get rid of the footgun ui.use_native_popup_windows preference.
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2011-06-16 22:43:02 PDT
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?
Comment 16 Stuart Morgan 2011-06-17 05:15:02 PDT
(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.
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2011-06-17 09:57:06 PDT
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 18 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-06-17 10:05:10 PDT
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 19 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-06-17 15:50:04 PDT
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]:
-----------------------------------------------------------------
Comment 20 Stuart Morgan 2011-06-17 18:40:53 PDT
(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 :)
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2011-06-17 19:14:02 PDT
> 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.
Comment 22 Matt Brubeck (:mbrubeck) 2011-06-22 10:12:00 PDT
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.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2011-06-22 10:37:16 PDT
This is fixed.

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