Closed Bug 336179 Opened 18 years ago Closed 16 years ago

Nested popup windows don't work

Categories

(Core :: XUL, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: brettw, Unassigned)

References

Details

(Keywords: qawanted)

Attachments

(1 file)

935 bytes, application/vnd.mozilla.xul+xml
Details
Make a popup with ignorekeys=true, and then put a menulist inside of it. Instead of the menu showing up under the menulist, the menulist is squashed and the menu shows up on the right side.
Please attach a XUL testcase showing the problem.
Keywords: qawanted
Flags: blocking1.9a2?
Attached file testcase
So this is the problem?
The longest menuitem inside a popup isn't completely visible and indeed, the menu shows up on the right side or the left side when on the right side there isn't enough space.
But I don't need ignorekeys=true for this.
Why do you need to put a menulist inside a menu?

It's obvious from the example that the menulist is behaving like a <menu>, which is would do since it uses display="xul:menu", creating a MenuFrame, and making it behave like the menulist contents was a submenu. You can see that the menulist popup appears on hover and to the right like any other submenu.

It would probably work to just skip menulists also at http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsMenuFrame.cpp#504
Brett, does that testcase accurately represent the issue you ran into?  Does making Neil's proposed change make things work?
Component: Widget → XP Toolkit/Widgets: XUL
(In reply to comment #4)
> Brett, does that testcase accurately represent the issue you ran into?  Does
> making Neil's proposed change make things work?

Annie says this is the bug (she's pretty busy with other stuff right now). I don't really understand the proposed fix.
I believe the idea is that in addition to checking !isMenuBar you'd add a similar check for menulists....
*** Bug 344075 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> The first issue is bug 336179, which will be fixed by the popup redesign in bug
> 279703. The second issue is the correct behaviour. Menulists do not support
> hierarchies and selecting something from a submenu should close up all menus.
> 
> 
> *** This bug has been marked as a duplicate of 336179 ***
> 

Neil, you probably forgot to cc you on the bug :)

Why is it correct behaviour? If menulist don't support hierarchies and they shouldn't then what is equivalent for it?
Equivalent for what?

The example you gave in the other bug has a menulist inside another menulist. Menulists are for selecting an item from a list. I'm not sure what you are expecting to happen.
(In reply to comment #9)
> Equivalent for what?
> 
> The example you gave in the other bug has a menulist inside another menulist.
> Menulists are for selecting an item from a list. I'm not sure what you are
> expecting to happen.
> 

Yes, probably menulist is designed for selecting items from a list only and it should be used for that only. But then we should have control that will looks as textbox with drommarker linked with popup. Now I can see one usecase for it. It's datepicker control. As I can see datepicker control should looks like menulist but when I open popup then I should see calendar widget. The calendar widget should have menulist for month and year selecting.

You can see related bug 280373, that bug has testcase that try to show datepicker partically :). Or If you'd like you can look at sunbird's datepicker. If I'll get right then sunbird's guys do the next. They use menulist that contains their custom xbl (calendar widget) in menupopup, calendar widget has popup for months, when someone choose month then menulist's popup is closed for sure. And then they open menulist's popup again. It's bogus, at least for me. I belive we should have solution for that.

Again, if menulist isn't designed for this and since we haven't control for realization something like datepicker then I should be able to create it. For that I need a possibility to show menulist (or popups) inside of popup.

Neil, does this usecase work for you?
btw, if menulist is designed for item selecting from a list then why does menupopup allow to put random elements into it?
(In reply to comment #4)
> The first issue is bug 336179, which will be fixed by the popup redesign in bug
> 279703.

Neil, will your patch of bug 279703 be checked in only on trunk or will it be checked in on 1.8 branch too?
Yes, I know that the calendar datepicker is using a menulist. It should not be. I plan on fixing that when the datepicker is moved to toolkit.
(In reply to comment #13)
> Yes, I know that the calendar datepicker is using a menulist. It should not be.
> I plan on fixing that when the datepicker is moved to toolkit.
> 

I can see several isssues:

1) Since menulist is designed only for items seleecting from a list then menupopup shouldn't allow to put any items extepting menuitem elements.

2) Also if menulist can't be used for it then we probably should provide element that will help to simplify to create widgets that looks like menulist and can have random content inside pupup.

3) I should be able to place menulist (or popup) inside popup.

Right?
Flags: blocking1.9a2? → blocking1.9-
This isn't really a problem any more; you can use <panel> to put menulists inside.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: