Bug 6545 (int-150319)

Summary: HildonAppMenu doesn't show when another top level widget is around
Product: [Maemo Official Platform] Desktop platform Reporter: Luca Donaggio <donaggio>
Component: hildon-widgetsAssignee: Alberto Garcia Gonzalez <agarcia>
Status: VERIFIED FIXED QA Contact: hildon-libs-bugs
Severity: normal    
Priority: Low CC: agarcia, andre_klapper, csaavedra, eopage
Version: 5.0/(2.2009.51-1)Keywords: patch
Target Milestone: 5.0/(10.2010.19-1)   
Hardware: x86   
OS: Maemo   
Attachments: Sample C code to showcase HildonAppMenu behaviour
Close the menu only when a modal window appears

Description Luca Donaggio (reporter) 2009-12-03 16:28:43 UTC
SOFTWARE VERSION:
Maemo 5 SDK Final

EXACT STEPS LEADING TO PROBLEM: 
1. Create a HildonProgram with a HildonWindow and HildonAppMenu
2. Show an undecorated top level GtkWindow somewhere over the HildonWindow and
make it transient for it
3. Click on the HildonWindow title bar

EXPECTED OUTCOME:
HildonAppMenu should appear

ACTUAL OUTCOME:
It indeed begins to appear, but it immediatly disappears

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:
It seems to depend from this function inside hildon-app-menu.c from lines 494
onwards:

static gboolean
hildon_app_menu_find_intruder                   (gpointer data)

It hides the HildonAppMenu if there's another top level widget around.
This prevents an app to have nice-looking, cairo-based, semi-transparent
widgets floating over the application's main HildonWindow.

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.15)
Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Comment 1 Luca Donaggio (reporter) 2009-12-03 16:45:29 UTC
Created an attachment (id=1658) [details]
Sample C code to showcase HildonAppMenu behaviour

This code creates an HildonProgram, adds an HildonWindow and an HildonAppMenu,
writes something inside a GtkLabel to add a visible background to the main
HildonWindow, creates a transparent, undecorated, pop-up window on top of the
HildonWindow and writes something in it as well.
By clicking on the holdonWindow title bar you can see for a brief moment the
HildonAppMenu appearing, then it disappers.
Comment 2 Claudio Saavedra 2009-12-07 14:05:42 UTC
I'm not sure if this can be fixed anyhow. The use case you describe is sort of
a hack.
Comment 3 Ed Page 2009-12-07 17:37:01 UTC
Unfortunately I have other priorities right now but previously I had issues
running an AppMenu with Dialcentral/ejpi/Gonvert and I wonder if it is related.
Comment 4 Alberto Garcia Gonzalez 2009-12-09 19:01:32 UTC
(In reply to comment #0)
> It seems to depend from this function inside hildon-app-menu.c from
> lines 494 onwards:
>
> static gboolean
> hildon_app_menu_find_intruder                   (gpointer data)

Yes, that was introduced to fix a race condition when a dialog and a
menu appared at the same time and the whole UI froze.

Many things changed since then (in particular: HildonAppMenu does no
longer use a grab) and this might not be necessary anymore, so it's
definitely worth having a look again.

Thanks for reporting the problem and uploading the test case.
Comment 5 Alberto Garcia Gonzalez 2009-12-10 18:47:22 UTC
Created an attachment (id=1725) [details]
Close the menu only when a modal window appears

Unfortunately we still need to close the menu when a dialog appears
below it, I've just checked and the original problem is still there.

However, I think that checking for modal windows is enough to avoid
that problem and doesn't interfere with other types of windows (such
as the one in your example).

I'll test this solution a bit more and try to have it published.

Thanks again for reporting the problem.
Comment 6 Alberto Garcia Gonzalez 2009-12-10 18:52:16 UTC
Adding patch keyword and alias for the internal bug
Comment 7 Alberto Garcia Gonzalez 2010-01-11 11:56:59 UTC
This has been fixed in libhildon 2.2.10-2+0m5
Comment 8 Andre Klapper maemo.org 2010-01-11 15:49:54 UTC
This has been fixed in package
libhildon 2.2.10-2+0m5
which is part of the internal build version
2010.01-6
(Note: 2009 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 9 Andre Klapper maemo.org 2010-03-15 20:54:12 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).