Since the SDK currently lacks a good, standard way to set up a preferences window, panels seem to be a good way to work around it.
But if you include a <select> element in your panel's content, bad things happen.
The URL linked in this bug has a reduced testcase that shows the problem. (It's on Builder, so you just hit the test button to install it.)
The testcase sets up a panel object and shows it immediately. The panel's content contains only the select element and its options. If you click outside of the panel, the panel goes away (as expected).
But if you click the select element in the panel, that's where things go badly.
As you can see (because of the panel's reduced height), the <select>'s options dropdown appears behind the panel, and (at least for me on Win7), the options are completely black, and do not get selected by click events. If you click on the select element, you can change the values with the keyboard arrow keys.
Now that you have clicked the select element, try clicking outside of the panel to hide the panel. Doesn't work. The only way to hide the panel (that I've found, at least) is to hit the 'esc' key on the keyboard.
Actual results: Select breaks a lot of stuff in the panel, and doesn't work correctly.
Expected results: Select works correctly and doesn't break the panel.
I'm on the latest 4.0b13pre nightly, if that matters.
I probably should have linked the panel to a widget element so the panel can be shown more than once without having to reload the entire extension, but I wanted the testcase as simple as possible.
Didn't see the other bug about this in my search until after I filed.
*** This bug has been marked as a duplicate of bug 633854 ***