Revision: 39760
Author: philip.breau
Date: January-23-14 3:32:19 PM
Message:
MOBI-994
menuItem in menuButtons disappears in IE9 after submit

• render a data-lastselected attribute to force the DOM update to include the entire menuButton
• also fix invalid snId, pcId, and singleSubmit attributes

  ---

  Modified : /icemobile/trunk/icemobile/core/src/main/java/org/icemobile/component/IMenuButton.java
  Modified : /icemobile/trunk/icemobile/core/src/main/java/org/icemobile/renderkit/MenuButtonCoreRenderer.java
  Modified : /icemobile/trunk/icemobile/core/src/main/java/org/icemobile/renderkit/MenuButtonItemCoreRenderer.java
  Modified : /icemobile/trunk/icemobile/jsf/components/component/resources/org.icefaces.component.util/component.js
  Modified : /icemobile/trunk/icemobile/jsf/components/component/src/org/icefaces/mobi/component/menubutton/MenuButtonItemRenderer.java
  Modified : /icemobile/trunk/icemobile/jsf/components/component/src/org/icefaces/mobi/component/menubutton/MenuButtonMeta.java
  Modified : /icemobile/trunk/icemobile/jsp/src/main/java/org/icemobile/jsp/tags/input/MenuButtonTag.java
  Modified : /icemobile/trunk/icemobile/jsp/src/main/javascript/icemobile.js

From Judy:

When I stepped through the debugger very slowly (javascript in IE9), I found that I put a breakpoint in the reset() function, then the update happened correctly. Are you sure this isn’t a timing thing? The update is not getting done or crashing with the reset function? I was considering that a timeout (just to test) on the reset might work or to have the reset function triggered on the onAfterUpdate callback. The markup was always good (from my testing yesterday) until the reset hits before or during the update.
If you update the entire region, you may end up with other problems with the reset function since the elements may not be present to run the reset, correct?

A workaround is to force a larger DOM update. In this case, the parent <li> element can have the current selected contentPane bound to it's class attribute like so. This prevents the DOM updates containing single <option> elements:

<li class="mobi-list-item #

">
<h:panelGroup style="float:left">
<mobi:menuButton id="selectedPanel" style="float:right" buttonLabel="Action" >
<mobi:menuButtonItem label="FirstPanel" id="m1"
value="inboxPanel"
actionListener="#

" />
<mobi:menuButtonItem label="another panel" id="m3"
value="anotherPanel"
actionListener="#

" />
</mobi:menuButton>
</h:panelGroup>
</li>

I can reproduce this in IE9 now too. I'm not sure exactly why this happening, but there seems to be a problem happening in the DOM update causing this. As mentioned above, a DOM update that includes just the <option> element of the selected menuButtonItem is returned from the server, which may result in a corrupted DOM node with only the text replacing the option element.

My guess is that this may be happening for the follow reasons.

• a fundamental problem with the menuButton component rendering invalid <option> markup. The option element is not supposed to have a 'name' attribute, as it is not a basic form element, the parent <select> element is. Changing this with the current component is difficult as the menuButtonItem does it's own decoding.
• the DOM update code cannot reliably update a single option element, resulting in the corrupted DOM. A workaround may be to force a larger DOM update which includes the parent elements.

please review the comments and let me know if you want a test case (using ant or pom for maven) reproducible on the current trunk

response from choosing Shipper At Risk option:-
<?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="messagingOptionsForm:mnu:selectedPanel:_t14">
<Unable to render embedded object: File (mnu:selectedPanel:_t14" name="messagingOptionsForm:mnu:selectedPanel:_t14" singleSubmit="false" value="shipperAtRiskPanel">Shipper At Risk</option>]]></update><update id="messagingOptionsForm:mnu_hidden"><) not found.[CDATA[<input id="messagingOptionsForm:mnu_hidden" name="messagingOptionsForm:mnu_hidden" type="hidden" />]]>.......then contentStack which is all good .....

then the reset is done. When I step through the debugger, line by line, none of the options disappear (usually in IE9, it's just the one that was chosen). Without stepping through, the option disappears. Makes me wonder if I should not do a timeout after the request and before the reset to try in IE? Could this be a timing problem? Perhaps do the reset with a callback for onAfterUpdate? (or onSuccess & onComplete?).

able to reproduce in test case with following page:-
<h:body>
<mobi:pagePanel>
<f:facet name="header">
header
</f:facet>
<f:facet name="body">
<mobi:largeView>
<mobi:tabSet id="mainTabSet"
selectedId="#

"
autoWidth="true"
fitToParent="#

" singleSubmit="true"/>
</mobi:fieldsetRow>
</mobi:fieldsetGroup>
</h:form>
</mobi:contentPane>

</mobi:tabSet>
</mobi:largeView>
</f:facet>
</mobi:pagePanel>
</h:body>

....note that the values are still in the page, just not showing:-
here is the markup for the attached screen shot
<span id="messagingOptionsForm:mnu:selectedPanel_btn" class="mobi-menu-btn-btn mobi-button ui-btn-up-c">
<span>Action</span>
</span><select id="messagingOptionsForm:mnu:selectedPanel_sel" onchange="ice.mobi.menubutton.select('messagingOptionsForm:mnu:selectedPanel');" class="mobi-menu-btn-menu" name="messagingOptionsForm:mnu:selectedPanel_sel">
<option value="">Select</option>FirstPanelShipper At Riskanother panel</select>

when looking at the markup in developer's tools it appears correct, but when copying innerHTML, you can see that it no longer appears accurate (the option is not getting rendered, just the label for the option.
(see screenshot).