Created attachment 516585 [details] Minimal testcase that can be run in js console The title tells all the story. This error, having <select> not working in a panel, only happens when you get all these conditions: - a panel - with an iframe inside of it - another iframe anywhere else - a <select> inside of this second iframe - and you are swaping iframe content with swapFrameLoaders from the second iframe to the first one that is in the panel. Just to be clear, <select> are working fine in panel, even inside an iframe. I've added that this platform bug is blocking addon-sdk bug 633854, but we may try to find some simplier alternative to avoid this current one.
Presumably a regression from bug 449734: we're not reparenting the combobox widget. Of course the fix to lazily create those widgets would fix this too...
Boris: any thoughts on when this might get fixed? A fix would be really handy for addon developers, who use popup panels with HTML forms containing select menus to solicit preferences from addon users.
Now that bug 610391 landed, I would expect this is fixed. Is it not?
And are the addon developers in question seriously using swapFrameLoaders?
Based on Alex's testcase in comment 0, it looks like this is still broken. Alex: can you test again and confirm? Boris: it isn't the addon developers who are using swapFrameLoaders; the API implementers are using them under-the-covers as part of the implementation of the Panels API.
> Based on Alex's testcase in comment 0, it looks like this is still broken. Ah, indeed. In that case, I'm not sure what's going on here.
No it's still buggy on today's windows nightly.
Determining exactly what broke this would be useful. There seems to be a large range of nightlies (somewhere in sept 2010 to around jan 2011) where the testcase doesn't open a panel at all so I can't narrow it down.
Any change with the latest Nightly?
Created attachment 535874 [details] [diff] [review] patch Ehsan's work to only create dropdown widgets when we open the dropdown probably fixed most of this already. But it is not completely fixed. If we swap frame loaders while a dropdown is open we'll probably still have bugs, but I doubt it matters. We weren't computing the display root view correctly (the frame version was correct). We were looking for a floating view that is a child of a non-floating view. But when we have a dropdown in a panel the dropdown is the display root but its parent is floating (because floating-ness gets propagated to all child views, more or less).
(In reply to comment #10) > (because floating-ness gets propagated to all child views, more or less). It doesn't always get propagated, but the view removing/inserting that swapping the frame loaders does I guess means that it gets propagated.
Comment on attachment 535874 [details] [diff] [review] patch Review of attachment 535874 [details] [diff] [review]: -----------------------------------------------------------------