548734 - ui.use_native_popup_windows breaks <select> dropdowns

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Hexadecima]

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 [:bzbarsky]]

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

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 [:bzbarsky]]

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

[Sait Umar]

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 [:bzbarsky]]

Argh.  We should probably just make this not work as a user_pref.  roc, thoughts?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We should just ignore the pref when the build doesn't have support for native select popups.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

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)]

That sounds good.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Which "that"?  Compile-time flag?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: Get rid of the footgun ui.use_native_popup_windows preference.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: 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]

(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 [:bzbarsky]]

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 (Exited; not receiving bugmail, old account, do not use)]

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)]

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]

(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 [:bzbarsky]]

> 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)]

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 [:bzbarsky]]

This is fixed.