The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla7

Status

()

Core
XP Toolkit/Widgets: XUL
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: ochameau, Assigned: tnikkel)

Tracking

Trunk
mozilla7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [blocks jetpack])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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...
Blocks: 449734
Assignee: nobody → matspal
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.
(Reporter)

Comment 7

6 years ago
No it's still buggy on today's windows nightly.
(Assignee)

Comment 8

6 years ago
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.

Updated

6 years ago
Blocks: 649144
Whiteboard: [blocks jetpack]
(Assignee)

Updated

6 years ago
Keywords: regressionwindow-wanted
Any change with the latest Nightly?
(Assignee)

Updated

6 years ago
Keywords: regressionwindow-wanted
(Assignee)

Comment 10

6 years ago
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).
Assignee: matspal → tnikkel
Attachment #535874 - Flags: review?(roc)
(Assignee)

Comment 11

6 years ago
(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]:
-----------------------------------------------------------------
Attachment #535874 - Flags: review?(roc) → review+
(Assignee)

Updated

6 years ago
Whiteboard: [blocks jetpack] → [blocks jetpack][needs landing]
(Assignee)

Comment 13

6 years ago
http://hg.mozilla.org/projects/cedar/rev/04b969002ce8
Whiteboard: [blocks jetpack][needs landing] → [blocks jetpack][needs landing][fixed in cedar]
Pushed:
http://hg.mozilla.org/mozilla-central/rev/04b969002ce8
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [blocks jetpack][needs landing][fixed in cedar] → [blocks jetpack]
Target Milestone: --- → mozilla7
You need to log in before you can comment on or make changes to this bug.