I noticed that for some reason the JSF bridge was sending the params that were part of the previous request. So when I tried to debug it, It came across that jsf.js keeps the previous queryString to build the new request in some cases (according to my understanding).

/**

• This function does final encoding of parameters, determines the request method
• (GET or POST) and sends the request using the specified url.
• @ignore
  */
  req.sendRequest = function() {
  .....
  // Some logic to get the real request URL
  if (req.generateUniqueUrl && req.method == "GET") { req.parameters["AjaxRequestUniqueId"] = new Date().getTime() + "" + req.requestIndex; }

  var content = null; // For POST requests, to hold query string
  for (var i in req.parameters) {
  if (req.parameters.hasOwnProperty)

  Unknown macro: { if (req.queryString.length > 0) { req.queryString += "&"; } req.queryString += encodeURIComponent(i) + "=" + encodeURIComponent(req.parameters[i]); }

  }

So once you have clicked a menuItem which has a param defined on it, it becomes part of the queryString, so next time you click a menuItem that doesn't have any param, the jsf bridge takes the previously defined param and add it into the request.

Maybe its due to the reason that the menuItems are using full submit?

return iceSubmit(form,this,event);

By looking at the generated HTML markup it seems link JSF doing the right thing. As the commandLinkRenderer creates a hidden field for its "params" and also uses a full submit onclick.

For example:
If a menuItem is using a param called "myParam", it would generate the following HTML markup.

<form>
//menuItem with param
<a onclick="var form=formOf(this);form['iceform:j_idcl'].value='iceform:menuBar:file:recent:file2:para2:link';
form['myParam'].value='Para 2';
return iceSubmit(form,this,event);">

//menuItem without any param
<a onclick="var form=formOf(this);form['iceform:j_idcl'].value='iceform:menuBar:edit:copy:link';
return iceSubmit(form,this,event);

//generated by commandLinkRenderer for its param
<input type="hidden" name="myParam" value=""/>
</form>

Use case:
1- Clicked on first menuItem which has a param:

• myParam hidden field being set to "Para 2"
• full submit happens
• bean gets the "Para 2" as "myParam" value.

2- Clicked on a second menuItem without any param:

• myParam is still have old value "Para2"
• full submit happens
• bean gets still gets "Para 2" as "myParam" value.

As we can see that myParam value was never cleared, so seems like everything is right. Wondered why "myParam" being cleared in 1.8.2EE.

Comparison between 1.8 and Compat behaviour
-------------------------------------------------------------------

1.8

<a onclick="..form['myParam'].value='Para 2';">

1. In 1.8 if you click above commandLink, it sets param value and make a full submit. Here is the request header:

We can see myParam was set to Para 2, However firebug shows that myPAram hidden field remains empty in the client side HTML DOM. So when submit happen next time myParam being sent empty(e.g.)

Compat
----------
<a onclick="..form['myParam'].value='Para 2';">

1. In compat if you click above commandLink, it sets param value and make a full submit. Here is the request header:

We can see myParam was set to Para 2, and firebug shows that myParam hidden field get set with "Para 2". So when submit happen next time myParam being sent with previous value(e.g.)

Confirm that ICE-5224 fixes this issue.