Closed Bug 638430 Opened 9 years ago Closed 9 years ago

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


(Core :: XUL, defect)

Not set





(Reporter: ochameau, Assigned: tnikkel)



(Whiteboard: [blocks jetpack])


(2 files)

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...
Blocks: 449734
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.
Blocks: 649144
Whiteboard: [blocks jetpack]
Any change with the latest Nightly?
Attached patch patchSplinter Review
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).
Assignee: matspal → tnikkel
Attachment #535874 - Flags: review?(roc)
(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]

Review of attachment 535874 [details] [diff] [review]:
Attachment #535874 - Flags: review?(roc) → review+
Whiteboard: [blocks jetpack] → [blocks jetpack][needs landing]
Whiteboard: [blocks jetpack][needs landing] → [blocks jetpack][needs landing][fixed in cedar]
Closed: 9 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [blocks jetpack][needs landing][fixed in cedar] → [blocks jetpack]
Target Milestone: --- → mozilla7
Moving to Core:XUL per
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in before you can comment on or make changes to this bug.