Gmail Labels not displayed as expanded

So... the accounts which -are- collapsed... when you click on the folder label...
...does it spawn a new tab? (like other expanded accts) 
Or just opens the folder in the same tab and collapses the view.

So... are you talking about the acct/folder list in the X-Notifier sidebar / X-Notifier window?

I have some 'labels' (folders) defined on one of my three gmail accounts...
...if it is already expanded, I can click the acct name - goto inbox, or just click the folder - goto folder ... stays expanded
...if it is collapsed, I can click the acct name - goto inbox, auto-expands folders... click folder - goto folder ... stays expanded.
Also, of course... the little arrow can be clicked to expand/collapse the acct/folders without going anywhere.

I am not seeing anything 'auto-collapse'.  If they are expanded, they stay that way when I restart browser. If collapsed, they stay collapsed... until I expand with the arrow, or click the acct name. If I close browser with them expanded, they will be expanded when I reopen.

Note: I have some of my emails 'aliased' with a 'group' prefix so they are indented in the X-Notifier window/sidebar, under the group header.

Are you using a Firefox variant?

@Tr3b: Apart from the problem you describe, it seems to me you are not aware of how to define the folder view. It is a checkbox per account in the XN Options: Show labels. It simply sets a hidden setting (about:config), named showFolders. In your case I guess it is (default) checked for all your Gmail accounts. (You can change the default value in the hidden settings too)

In my logic, settings are not expected to get set by (un)collapsing an account in the XN accounts view. I can understand you would expect it to behave in that way thow... It might be a glitch of the Mozilla API when used with Cyberfox (I'm just guessing). Or it might get solved by uninstalling, cleaning registry and reinstalling Cyberfox (guessing again). And remember software is made by humans, who are known to produce mistakes. Or the (human) software developer didn't anticipate a certain scenario to take place.

Ok, it is obviously the Event mechanism that is failing here:
The (MouseClicked or MouseDown)  event for arrow clicked and the event for account or account folder clicked are "merged" (both events get triggered in both occasions, so both event handlers get executed).

I might have an idea what is going wrong here. Both event handlers should consume the event after dealing with it (this.event.consume() as last code statement in the eventhandler method implementation) . The event gets propegated (passed on) to the other existing event handlers (with Cyberfox).

I am "triggered" (challenged) now to have a look at the code ;-)

Found the two event handlers in xn-overlay.js:
(they get assigned in xn-overlay.xul)
onTreeClicked: function(event)
openViews: function(event)

The Javascript Event interface does not have a consume() method like Java, C++ and C# have, but a stopPropagation() method and a readonly bubbles property (A boolean indicating whether the event bubbles up through the DOM or not).
(It used to be the cancelBubble(), which is obsolete since Gecko 24)

Neither of the two event handlers end with
if(event.bubbles) event.stopPropagation();
and I really think they (as the majority of eventhandlers) should...
So I will suggest it to admin by email, expecting it will solve Tr3b's problem.

I know: too much info, but I couldn't stop myself ;-)

Please test this version works for you.

https://addons.mozilla.org/en-US/firefox/addon/xnotifier/versions/3.5.10

Tr3b, correct me when I am wrong:
I am guessing you mean nothing has changed by the fix.
Well, that's a pity, but my fix was kind of a longshot.

I am still wondering, since you only passed the info halfway this thread that you are using Cyberfox, whether you had X-notifier ever working correctly with Cyberfox in this aspect at any time. When that is the case I would still recommend to do a total deinstall, clean (including registry) and reinstall of both X-notifier and Cyberfox.

When not fixable by above procedure, you might consider a reality that this is not a X-notifier bug, but possibly an incorrect behavior of mouse events in Cyberfox, while working with add-ons. I could be considered very stout to draw such a conclusion, but the fact Firefox is working correctly in this aspect is my advocate.

I tested X-notifier with Cyberfox.

It works fine.

I have no idea what is wrong.

Tr3b, the collapsed state of that folder is (as confirmed by admin over email) not handled by X-notifier (javascript) code. It is html (a DOM object in the html) handled by Cyberfox program code. So the setting gets locally cached by Cyberfox (in a hidden Cyberfox folder on your computer). And reading your observation the functionality gets reversed (doing the opposite), I get the impression the cached setting is a so-called 'toggle', meaning it is a variable that either is true or false (zero or one) which gets its value by being toggled. Such a variable is called a boolean and either false or true. Lets assume the boolean is named collapsedState in the Cyberfox program code. Then the toggle code could be collapsedState=!collapsedState, meaning when its value is true it becomes false and vice versa. This is a style of coding that is considered unsafe (error-prone), because it is not explicit, possibly causing the result you are experiencing in certain circumstances (like a Cyberfox crash).

Did you execute what you mentioned earlier: to start a new Cyberfox profile?

Well, I am lost for words now: NOT Cyberfox related at all?

(Export your X-notifier accounts)
Easy to test then:

1. Start new profile
2. Install X-notifier
3. Add your one problem account

[edited] Our posts crossed in Cyberspace time, Tr3b ;-)