After invalidateOptionsMenu() ; items no more clickable #510

aguillard opened this Issue Jun 7, 2012 · 17 comments


None yet


I've just discovered a bug since I have updated to version 4.1.0

On this version, if I call :


After that, items on the actionbar are no more clickable.

If tested also in the version 4.0.2, the bug is also present.

For now, I've reverted my code to the version 4.0.1

To add more information, this happens to me only when actions that are not visible and become visible after the invalidateOptionsMenu() call.
For some strange reason it seems that all the key events are buffered and replayed when I push any physical keys.

After some more tests I found that this happens when the visibility of items is changed while the whole action bar is hidden, so I just changed the code to be sure that visibility changes occur only when the bar is shown.


ghost commented Jul 19, 2012

frisco82, can you provide your workaround in detail?

I found this problem always on split action bar, the icons at the bottom bar are not clickable until some redraw is done, but for some strange reason the touch events are received but not translated to click events untill something else happens (back button, menu button, orientation change...).

This only happens when the view is initialized with an empty menu via onPrepareOptionsMenu returning false (or 0 visible items) or because the actionbar is hidden on onCreate.

So to avoid all this problems, I needed to make the action bar enabled by default (and hidden on touch as I am working on an image gallery) and onPrepareOptionsMenu always return true and at least one item.
Then I can invalidate the menu as many times as I want and all the buttons are clickable even if they where initialized as invisible.

Not sure what's the underneath problem, I tried to debug everything but it just seems like the touch events are not propagated correctly until something else "unlocks" them.


ghost commented Jul 25, 2012

thanks, i'm going to try this out

I've also find a workaround for this issue.

In my case, on my first implementation, on the method onCreateOptionsMenu(), I inflated the menu only in one condition. This condition was not true the first time that onCreateOptionsMenu() is called so the issue came during invalidateOptionsMenu().

To solve the issue, it's mandatory the inflate a menu the first time onCreateOptionsMenu() is called. And like this, we can redefine the menu after with invalidateOptionsMenu().

Any progress on this issue? Problem still exists in Version 4.2.0. Tested on Android 2.3.7.


SimonVT commented Oct 24, 2012

Adding a test case to the known bugs sample greatly increases the chances of anyone looking at this.

Thanks for the hint. Gonna try to reproduce it in a test case. No luck so far ...

@Konsumierer Konsumierer pushed a commit to Konsumierer/ActionBarSherlock that referenced this issue Oct 25, 2012

Sebastian Harder test case for issue #510 db8142a

I created a test case and a pull request. Seems like the problem is, that you may not call invalidateOptionsMenu() within the onCreate method of an Activity. This could be the case, if you want to update a Fragment with some data that was passed to the Activity via Intent and then decide which menu items to show in the Fragment.onPrepareOptionsMenu(..).

P.S. sorry for the first two commits

I've got the same issue with 4.2.0. I'am using a ViewPager/FragmentStatePagerAdapter with two Fragments without Tabs. After the first setCurrentItem on the ViewPager the action bar items get unresponsive. Their icons also gets darker, using the light theme with gray icons, so i suspects some double-draw, double-call issue.

It works fine if the Activity also adds items.

Happened for me too where I use a FragmentPageAdapter and the Fragments create the options menu. Simply adding

public boolean onCreateOptionsMenu(Menu menu) {
    return true;

to the activity seems to work around the issue and has no visual changes to the options menu.

Crazymaik: this is not a good idea. When pressing a hardware menu button, an empty menu item is displayed.

Happening here too, the menu.add("") seems to fix it, but why? Still sloppy and who wants an extra menu item hanging around unnecessarily.
Hasn't there been any advance with this issue in 8 months? any news?

Ereza commented Feb 14, 2013

I just stomped on this bug... I have applied crazymaik's solution, but with one change: adding a boolean variable to my activity so I only add the empty menu the first time. After that, it gets invalidated and does not show up when you press the menu key.

uKL commented May 15, 2013

I'm using the newest version of ABS but the problem still occurs. Adding empty menu item is just a workaround and users get confused after menu key click. Is there any better solution?

Having the same problem. Have to inflate all menus in activity...

Ereza commented Jul 22, 2013

After some months, I have modified my workaround, I'll explain it, hoping that it will help someone.

In my case, this bug happens because I have a fragment with an options menu, and the activity where it is attached has no menu. I really want to handle the options menu in the fragment, because that simplifies the menu handling on a tablet layout, where the activity does have a menu.

That being said, my fix was similar to the one indicated by crazymaik, but instantiating a real menu instead of adding an item. This way, we can better control how it is displayed.

In my activity (which had no menu and only contains the fragment which has one), I have added the following code:

boolean firstTimeMenu = true;
public boolean onCreateOptionsMenu(Menu menu) {
    if (firstTimeMenu){
        getSupportMenuInflater().inflate(, menu);
        firstTimeMenu = false;
    return super.onCreateOptionsMenu(menu);

fake_menu.xml is a menu containing the following:

<menu xmlns:android="" >
    <!-- We use this to workaround ABS bug #510 by instantiating this as a menu on our activity -->

Then, on my fragment I call getActivity().supportInvalidateOptionsMenu() as early as possible, in order to hide the fake menu.

The only effect visible to the user is that if you are using a title or subtitle on the action bar, if it is too large it will be shown with "..." while the fake menu is shown (only a moment).

This improves the previous solution because that solution showed an empty menu if you pressed the hardware menu key, or showed the overflow menu icon if the device had software buttons.

Of course, the best solution would be to have this bug fixed ;)

Having the same problem.
I use the workaround supposed by crazymaik with a little change:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment