633854 - Selects inside Panels don't render properly

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Hernán Rodriguez Colmeiro (:peregrino)]

Attachment: Testcase

If a select is inside a panel the the select's options don't render, only a blank dropdown is shown.

Attached is a main.js testcase.

Comment 1

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

Hmm, sounds like an issue with native widget rendering.

Comment 2

[Hernán Rodriguez Colmeiro (:peregrino)]

So what should we do about it? is not only that the select doesn't render properly, it also affects the hiding of the panel as it only will hide if you hit escape.

BTW, reading the XULPanel docs, I found this warning: 

"Note that placing an iframe, browser or editor inside a panel is not currently supported. Some features may work but only on some platforms. It is best to avoid child frames in a panel if possible."

May this be one of the "not supported" stuff on iframes inside panels?

Comment 3

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

(In reply to comment #2)
> So what should we do about it?

We should file a platform bug on it, attaching a minimal (non-SDK-based) testcase that demonstrates the problem.


> "Note that placing an iframe, browser or editor inside a panel is not currently
> supported. Some features may work but only on some platforms. It is best to
> avoid child frames in a panel if possible."
> 
> May this be one of the "not supported" stuff on iframes inside panels?

Perhaps, although that comment is a bit out-of-date, now that the fix for bug 130078 has landed.  My guess is that this is either a regression from the fix for bug 130078 or (more likely) a bug exposed by the fix for bug 130078.

Comment 5

[Alexandre Poirot [:ochameau]]

Attachment: Minimal platform bug testcase

This bug is complicated to reproduce from platform point of view!
In order to have it, you have to use both : panels, select, iframes and swapFrameLoader function !!!
If you remove one of these items, it works fine.

So I think that there is a platform bug around swapFrameLoader function which happens only when the destination frame is in a panel and this bug mainly breaks select, but I wouldn't be surprise it breaks another things.

I'm going to fill a platform bug and ask them to evaluate how many hairs they need to pull on this complex bug. But I think we may solve this issue (and potentialy others) on our side by simplifying panel code:

- Is panel persistence feature really justified ?

- Using swapFrameLoader is really powerfull but do we really need to ? I think using it is a major source of errors. There may be some solution using a custom hidden windows like I did in various project (yoono, jetintray, oop experiment)
Like this custom hidden window:
https://github.com/ochameau/jetpack-oop/blob/master/lib/ipc.js#L3
The only point that may not work easily is anchoring. I don't know if openPopup anchor can be given on a node from another window.

Comment 6

[Dietrich Ayala (:dietrich)]

(In reply to comment #5)
> Like this custom hidden window:
> https://github.com/ochameau/jetpack-oop/blob/master/lib/ipc.js#L3
> The only point that may not work easily is anchoring. I don't know if openPopup
> anchor can be given on a node from another window.

Cc'ing Enn, who might know the answer to this.

Comment 7

[Neil Deakin]

Since it works fine on a build from early Sept 15 and doesn't on a build a few days just afterwards, it is likely another regresssion from 130078 and friends.

I'm not entierly sure what you're trying to accomplish but using swapFrameLoader seems like the wrong choice. Why do you think you need it?

Comment 8

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

The Add-on SDK's Panel API lets addon developers create popup panels that can be shown and hidden as needed but whose HTML content is loaded on panel instantiation and remains loaded across panel shows/hides so that showing a panel is as immediate a user experience as it is for Firefox's built-in XUL panels and the XUL panels of traditional extensions.

When shown, panels are typically anchored to an element such as a widget in the Add-on Bar.  But the anchor can change between appearances of the panel.  Each browser window has its own Add-on Bar, and widgets appear in all windows, so the anchor might be the widget view in one window on one occasion and a different widget view in another window on another occasion (typically, it is the widget view for the active window at the time the panel is shown).

The implementation loads panel content in a frame in the hidden window upon Panel instantiation and stores it there until the panel is shown.  When the panel is shown, the implementation creates a XUL panel, anchors it to the anchor point, creates a frame inside the XUL panel, and swaps the frame loaders of the hidden window frame and the XUL panel frame to make the panel content appear in the XUL panel.

When the panel is hidden, the implementation swaps the frame loaders again to move the panel content back to the hidden window frame and destroys the XUL panel and its frame.

I welcome suggestions for alternative implementations that don't swap frame loaders, but they should respect the existing API, which is designed to provide a similar UX to other panels via a high-level interface that doesn't require addon developers to learn XUL, deal with multiple browser windows, or directly manipulate chrome DOM.

Comment 9

[Timothy Nikkel (:tnikkel)]

This should be fixed now. If not please reopen.

Comment 10

[Mingyi Liu]

May I ask how can I get the fixed code? I'm using 1.0b5 and seeing a similar bug - not blank select, but instead you can't use mouse to select any of the options. The down arrows does select fine, and mouse can select options inside a multiple-select. Only the 2nd to nth options in a dropdown select cannot be selected by mouse.

Comment 11

[Hernán Rodriguez Colmeiro (:peregrino)]

(In reply to comment #10)
> May I ask how can I get the fixed code? I'm using 1.0b5 and seeing a similar
> bug - not blank select, but instead you can't use mouse to select any of the
> options. The down arrows does select fine, and mouse can select options
> inside a multiple-select. Only the 2nd to nth options in a dropdown select
> cannot be selected by mouse.

You need to get a Firefox Nightly build and try there. The fix was something on the Firefox side, not the SDK.

Comment 12

[Mingyi Liu]

Thanks! The nightly 7.0a1 did fix the issue I saw as well, but I guess it'd take months to reach the common end users. A bit late for addon developers needing to use the Select dropdown menu in Jetpack ...

BTW I noticed the current nightly doesn't parse CSS color property if it's a hex value like #F00, #FF0000 (red or rgb(255,0,0) do work).