class=active only appended to manually added entries when SectionEditPlugin is active

[izzy]

The "active" class is not appended for menus trac itself provides - just for items added via the ![mainmenu] section in trac.ini. CSS depending on that (e.g. to emulate Trac-alike design, what I'm just trying) will fail to highlite original items. Only work-around is to use e.g. navhider to hide all menu items, and add them all again manually with new names - which is quite ugly...

[izzy]

This problem seems to be caused by menu_orig items having no "href" property (as I described in #4280), so they are not matched at line 84 of web_ui.py by if tree_node.get('href'), and thus the active flag will not be set at line 86 for them - just to hopefully point out where the fix must start. Somewhere the menu_orig items must have their href stored (otherwise they could not work in the menu), so this part must be considered as well.

[izzy]

Partly solving the problem using HDF

[izzy]

I just attached a patch which partly solves the problem by picking the URLs from the HDF object. This is more or less an ugly work-around. Does e.g. not work for the code browser (somehow here a "/" gets attached to the end - maybe for the /browser URL a separate handling is required - or the general match must be changed from tree_node_href[2]==req.path_info to something stating tree_node_href[2] must start with req.path_info, since the same problems may come up with some other tabs as well.

One problem still left is: When a sub-item is active, the parent should be marked active as well. But the parent at this time may be already parsed. I don't know how to achieve that.

You can take the patch as-is - but I guess you want to improve the code. Fell free to use it. If it even only gets you to the point for a better solution, I'm happy with it ;)

[Catalin BALAN]

I can't reproduce this defect.

Please provide trac and genshi version and your current [mainnav] section from ini config file.

Thank you, Catalin Balan

[Catalin BALAN]

oh, regarding setting parent item as active when sub-item is active, I believe that doing it client side should be a better choice.

This should do the trick:

$('#mainnav li.active').parents('li').addClass('active')

Will be added soon.

Thank you, Catalin Balan

[izzy]

Partly solving the problem using HDF

[izzy]

Catalin,

thanx for your response. I meanwhile updated the patch concerning the non-working items. It's still an ugly work-around - but (except for the parent-activation) seems to work for me. What it does:

1. check HDF for href (if name is "tickets", search for "report" instead). If found, replace the base_url by an empty string and set the result as tree_node['href']
2. if not found, try if the href is already set. in the except, set tree_node['href'] to "/name`"
3. when comparing, I don't do an exact match but use tree_node_href[2].startswith(req.path_info) instead (for the additional code matching with HDF only).

Just as a little explanation. Hope it will be useful.

Best regards, Izzy.

[izzy]

Ouch - I just found a side-effect to be solved in CSS, and I don't know how: If the parent gets active, the child is activated as well (since it is inside the active LI). How to tell the inner list item (i.e. the child) to not be activated just because of the parent is - but only if it is itself? I'm not the CSS Guru...

To explain: This happens when e.g. keeping "timeline" where it is, adding "roadmap" as child to it, and then clicking on "timeline". I did so to have the most used items reachable directly, so I did not want to activate the menu first to select the sub-item.

If there is no solution by CSS alone, maybe for "inactive" items a class "inactive" could be added. This way the "defaults" could be placed back to that class.

[izzy]

Replying to cbalan:

I can't reproduce this defect.

Please provide trac and genshi version and your current [mainnav] section from ini config file.

• Trac 0.11r7573 (stable branch)
• Genshi 0.4.4-2ubuntu1 (package python-genshi)

[mainnav]
tickets.label   = Tickets
newticket.parent = tickets
newticket.hide_if_disabled = 1
#special_report.href = /report
#special_report.label = List Tickets
#special_report.parent = tickets

roadmap.parent = timeline
worklog.parent = Billing
worklog.perm   = WORK_VIEW

new_wiki.href = /wiki/CanDo
new_wiki.label = Trac4BR
new_wiki.parent = top

[Catalin BALAN]

We'll need to deactivate li.active a rule from trac.css and set something like li.active > a Will be fixed soon.

Regarding active thing, line 86 is only needed for new added items from config. For original items, that should already be handled by Chrome.

But, I'll investigate, running your setup (trac-0.11r7573, genshi-0.4.4), to see if I can reproduce it.

Thank you, Catalin Balan

[izzy]

Replying to cbalan:

We'll need to deactivate li.active a rule from trac.css and set something like li.active > a

True. I just tried with a separate "inactive" class (changing the default in web_ui.py) with no success: Though DOM Inspector showed the right settings as "computed style", the browser shows the item as activated. So your suggestion seems to be the better one.

Will be fixed soon.

Great!

Regarding active thing, line 86 is only needed for new added items from config. For original items, that should already be handled by Chrome.

I thought so, too - but somehow my test environment showed different behavior. No idea why.

But, I'll investigate, running your setup (trac-0.11r7573, genshi-0.4.4), to see if I can reproduce it.

Thank you! If I can help somehow, please let me know. As stated, it is a test environment - so I can play a bit with the code ;)

Ah - some correction: I thought I used Genshi from the package, but that's not true. The installation runs Genshi-0.5.1 with Python 2.5 as an egg. I also just updated Trac to the latest revision (7763). Problem remains. What Genshi version are you using? I could try to update that as well.

Best regards, Izzy.

[izzy]

Just in case it may be a compatibility issue including other plugins:

[components]
acct_mgr.admin.accountmanageradminpage = enabled
acct_mgr.api.accountmanager = enabled
acct_mgr.htfile.htpasswdstore = enabled
acct_mgr.web_ui.accountmodule = enabled
acct_mgr.web_ui.loginmodule = enabled
acct_mgr.web_ui.registrationmodule = enabled
ctxtnavadd.web_ui.ctxtnavaddmodule = enabled
estimationtools.burndownchart.burndownchart = enabled
estimationtools.hoursremaining.hoursremaining = enabled
estimationtools.workloadchart.workloadchart = enabled
goodies.entities.entities = enabled
goodies.mailto.mailtolink = enabled
goodies.smileys.smileys = enabled
goodies.symbols.symbols = enabled
goodies.unc_paths.uncpathlink = enabled
graphviz.graphviz.graphviz = enabled
includemacro.macros.includemacro = enabled
includesource.* = enabled
iniadmin.iniadmin.iniadminplugin = enabled
lastmodified.lastmodified.lastmodifiedmacro = enabled
mediawiki.* = enabled
navcontrol.filter.navcontrolmodule = enabled
notebox.* = enabled
projectmenu.web_ui.projectmenumodule = enabled
removepending.remove_pending.removependingplugin = enabled
timingandestimationplugin.* = enabled
trac.web.auth.LoginModule = disabled
tracacronyms.acronyms.acronyms = enabled
tracfullblog.* = enabled
tracmenus.* = enabled
tracsectionedit.web_ui.wikisectioneditmodule = enabled
tractags.* = enabled
tractoc.macro.tocmacro = enabled
tracwysiwyg.* = enabled
wikinegotiator.macros.ntocmacro = enabled
wikinegotiator.macros.tocmacro = enabled
wikinegotiator.negotiator.wikinegotiatormenubar = enabled
wikitopdf.* = enabled
worklog.* = enabled

[izzy]

Found it! So here is the result: I temporarily disabled all non-essential plugins. Menu works as expected - the current one is highlighted. Then I enabled the plugins one by one - and guess what? There are conflicts with two plugins! When I enabled the WorkLogPlugin or SectionEditPlugin, the current menu item is no longer highlighted.

So currently, I simply left these two disabled. The more important for us may be the WorkLogPlugin, since it adds a complete new feature. SectionEditPlugin is very useful - but since one can edit the section also without it (with the disadvantage of having to search a lot on long pages), it becomes the secondary in this line. But if you can work around the one, it may fix the other as well - as long as you don't say it has to be fixed in the other plugins...

So I guess in order to reproduce the problem, you don't have to install a special version of Trac or Genshi - just install those two plugins, and you will see.

[izzy]

As for the SectionEditPlugin, the problem is caused by the JavaScript it adds:

(function($){
        $.fn.addEditlink = function(title){
                var cnt = 1;
                title = title || "Edit this section";
                return this.filter("*[@id]").each(function(){
                        $("<a class='anchor'>[<span>edit</span>]</a>").attr("href", "?action=edit&section=" + cnt++).attr("title", title).appendTo(this);
                });
        }

        $(document).ready(function() {
                 $(":header", $("#content")).addEditlink("Edit this section");
    });
})(jQuery);

Only the Wiki tab/menu item is affected here. I just commented out the code to include this JavaScript file, and re-installed the modified plugin - menu again works as expected. But in the JavaScript code, I cannot see what could cause the problem.

For the WorkLogPlugin, the source of trouble is harder to find (since it is a lot more code here, including 80kb of JavaScript code). I'm not that firm in this stuff, so I doubt I find it here...

[izzy]

Wow - WorkLogPlugin is fixed (see #4180). I applied the patch attached to the mentioned ticket, rebuilt and installed the egg, enabled the plugin again - menus still working! So concerning that plugin there is a solution available (just in case the question comes up again). Remains the SectionEditPlugin JavaScript problem - there is no ticket open. If I only understood what that code means - I might be able to find and fix the problem using the "try-and-error" method. But that kind of code I never worked with...

[izzy]

As this is caused by misbehaviour of other plugins (see #4180 and #4288), it is no issue to be solved here. As it is already solved for WorkLogPlugin (#4180), I opened #4288 for SectionEditPlugin (where the issue has to be solved) - and since here is nothing left to do, I close this ticket now.