638430 - <select> doesn't render correctly in iframe within a panel where we use swapFrameLoaders on it!

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Alexandre Poirot [:ochameau] [PTO back August 21]]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Now that bug 610391 landed, I would expect this is fixed.  Is it not?

Comment 4

[Boris Zbarsky [:bzbarsky]]

And are the addon developers in question seriously using swapFrameLoaders?

Comment 5

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Alexandre Poirot [:ochameau] [PTO back August 21]]

No it's still buggy on today's windows nightly.

Comment 8

[Timothy Nikkel (:tnikkel)]

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.

Comment 9

[u279076]

Any change with the latest Nightly?

Comment 10

[Timothy Nikkel (:tnikkel)]

Attachment: 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).

Comment 11

[Timothy Nikkel (:tnikkel)]

(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 12

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

Comment on attachment 535874 [details] [diff] [review]
patch

Review of attachment 535874 [details] [diff] [review]:
-----------------------------------------------------------------

Comment 13

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/projects/cedar/rev/04b969002ce8

Comment 14

[Mounir Lamouri (:mounir)]

Pushed:
http://hg.mozilla.org/mozilla-central/rev/04b969002ce8

Comment 15

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336