Adnan, please take a look. You might need to use the internal stage server (http://lnstage1.ice/main/ ) accessed via VPN.

Validation (using W3C validator) turned out OK. (Only a few non-critical errors repeated again and again.) HTML source code looks OK. The markup for the broken menuitem looks exactly the same as a working menuitem, but somehow it ends up changed in the Firefox DOM tree. So far, haven't been able to reproduce problem on IE.

There is an idea that perhaps the menuitem is firing an partialSubmit when it's clicked (via some JS on the onClick event handler) and that there is a race condition of some sort between the partialSubmit and the full GET that's done as a result of clicking the URL to another page.

Analyze the public icefaces.org menus to see if this might be the case via DOM inspection and HTTP traffic monitoring.

After several different tests and analysis, my best guess is that the problem is due to the <div> element rendered inside the <a> element, which is invalid markup according to both Document Type Descriptors: HTML 4.01 Transitional and XHTML 1.0 Transitional.

What to do? Remove that <div> element (which has no attributes, and therefore has no effects) from the renderer class of the menuItem component. This <div> element which contains an <img> and a <span> element, is absolutely unnecessary as the <a> element is already allowed to contain inline* elements, which include <img> and <span>.

Reasons

I first start by discarding some possible reasons.

The problem doesn't seem to be related to the Server DOM. Comparing several times the page source (from View > Page Source) showed that the markup returned by ICEfaces was always the same in both cases: when empty menu items appeared and when there were no such empty items.

The problem doesn't seem to be related to a parallel asynchronous request (i.e. partialSubmit). Monitoring with firebug showed that after clicking on a menu item there were no additional requests besides dispose-views (and the synchronous request itself). This was tested on every menu item.

The measures taken by Carlo suggest that the problem is at a lower level (the markup), and not in the ICEfaces response mechanisms. They also suggest that the problem is at an individual level. Using less menu items didn't solve the problem, and other elements combined with the menu items had no effect either for worse or for better.

Trying to add/remove attributes (i.e. id's and name's) didn't solve the problem either. So, the only thing left to try is to add/remove HTML elements, and we know that using a <div> element inside an <a> element is definitely wrong. So, we should try removing it.

Regardless of the results of this suggested change, having more valid markup will definitely reduce rendering problems in browsers by easing their job.

What are some possible causes of this problem?

We know that browsers start rendering a document as it is arriving (i.e. they don't wait until the HTTP response is finished to start rendering the document). They start creating the DOM tree from the first element received, then, depending on what is received later, they go back to fix the DOM. Depending on the rendering engine of the browser, there might be some cases when the browser thinks that there's nothing to be changed, when in fact it has to be changed, and it's left like that. This could be due to net latency and processor load at that precise moment. This could be why the problem doesn't happen locally.

Note that the markup shown by firebug is different to the markup shown in the View > Page Source window. The original markup doesn't show an additional <a> element, while firebug does show an additional, self-closed <a> element (as in the screenshot).

At some point, the page took relatively longer to load, to the point that I could see each of the menu headers being added one by one. This time there were 3 empty menu items.

Something that might have influenced this behaviour is that in past versions all image elements were rendered with a separate closing tag (i.e. <img></img>) and now they are being rendered with a single self-closed tag (i.e. <img />, which is valid).

• According to the HTML 4.01 Transitional DTD, only the following elements can appear inside an <a> element: <tt>, <i>, <b>, <big>, <small>, <em>, <strong>, <dfn>, <code>, <samp>, <kbd>, <var>, <cite>, <abbr>, <acronym>, <a>, <img>, <object>, <br>, <script>, <map>, <q>, <sub>, <sup>, <span>, <bdo>, <input>, <select>, <textarea>, <label>, and <button>. Source: http://www.w3.org/TR/html401/sgml/dtd.html

Recommend restoring the server-side "debug DOM update" functionality and including the relevant output here to confirm the source of the problem (if the server-sent update does not contain <a/> then we know that the browser is modifying the DOM later).

Removed the rendering of a <DIV> tag within an <A> tag, inside menu items. Now the <IMG/> and <SPAN> children go straight winthin the <A>.

TRUNK : Subversion 16103
icefaces\component\src\com\icesoft\faces\component\menubar\MenuItemRenderer.java

ICEfaces 1.6 Branch : Subversion 16104
icefaces\component\src\com\icesoft\faces\component\menubar\MenuItemRenderer.java

It's been several days, with no reported sightings of the glitch. Looks fixed to me.