We recently upgraded from version 7.3 to 8.2. We made no changes to our menu logic, but our menu is broken. Has anyone else seen this situation?
We set various menu items using the TargetUrl property. Our logic is very similar to the link below. Our URLs pass information via the querystring. It now seems like the UltraWebMenu encodes/decodes the TargetURL differently which is breaking our links. Specifically we've seen ampersands changed to the encoded version of an ampersand (&). We've also seen other encoded characters (plus sign, etc.) change when the actual menu item is clicked. This may be related to the ampersand issue though.
Please let us know ASAP...
LINK:
http://help.infragistics.com/Help/NetAdvantage/NET/2008.2/CLR2.0/html/WebMenu_and_WebTree_Use_TargetURL_to_Run_JavaScript.html
Hello,
Could you please send a little bit more information about the WebMenu declaration. ASPX declaration, code-behind – anything that can get us started is welcome. Can be have many reason for that issue especially after the update.
Thanks.
Hi Ivan -
Thanks for the quick response. Some of the details are below. Please let me know if there is other info that you need:
ASPX:
<ignav:UltraWebMenu ID="UltraWebMenu1" runat="server" BorderColor="Transparent" BorderStyle="None" JavaScriptFilename="" JavaScriptFileNameCommon="" LeafItemImageUrl="" ParentItemImageUrl="" StyleSetName="" Width="28px" Cursor="Hand" SeparatorClass="" > <ItemStyle Cursor="Default" BackColor="White" /> <Images> <SubMenuImage Url="ig_menuTri.gif" /> </Images> <TopLevelHoverItemStyle BackColor="Transparent" ForeColor="Black"></TopLevelHoverItemStyle> <IslandStyle BackColor="White" BorderStyle="Outset" BorderWidth="1px" Cursor="Default"> </IslandStyle> <HeaderStyle BackColor="White" /> <HoverItemStyle Font-Underline="true" BackColor="#000066" Cursor="Hand" ForeColor="White"> </HoverItemStyle> <Levels> <ignav:Level Index="0" LevelClass="" LevelImage="" /> <ignav:Level Index="1" /> </Levels> <DisabledStyle Font-Names="MS Sans Serif" Font-Size="8pt" ForeColor="Gray"> </DisabledStyle> <SeparatorStyle BackgroundImage="ig_menuSep.gif" CssClass="SeparatorClass" CustomRules="background-repeat:repeat-x; " /> <ExpandEffects ShadowColor="Transparent" ShadowWidth="1" Type="Iris" /> <Items> <ignav:Item ImageUrl="./_images/mg_icon.gif" Text="MGS" > <Images > <DefaultImage Url="./_images/mg_icon.gif" /> </Images> <Styles BackColor="White" Font-Names="Arial" Font-Size="7pt"> <BorderDetails StyleBottom="None" StyleLeft="None" StyleRight="None" StyleTop="None" /> </Styles> </ignav:Item>
<MORE ITEMS HERE - SIMILAR TO ABOVE (SOME WITH 2 LEVELS)>
Code Behind Snippets:
string domain = WebConfig.GetSetting("domain");
this.UltraWebMenu1.Items[(int)menuList.MGS].TargetUrl = "BLOCKED SCRIPTwindow.open('" + domain + "rd/MGS.aspx?CID=" + this.SelectedCID + "&AN=" + EncryptionUtility.EncryptAndEncode(ddlAccounts.SelectedValue) + "','','width=350,height=400');";
After some ugly digging, I think I found the issue. The issue seems to be in the __igmenu_navigateUrl javascript method. See below for a reference. The problem is that the code looks for the index of the string "BLOCKED SCRIPT". If the index is greater than 0 it does an eval on it. The issue is, if the string starts with this text the index will be = 0 (not greater than). Another issue is that our code had a capitol J and S in JavaScript. Again, this worked in 7.3. I changed our code to have all lowercase "BLOCKED SCRIPT", and a space to start the string (so the index is GREATER than 0), and it works again. Pretty hacky though.
Another consideration is the unescape logic below. If the javascript text isn't found, an unescaped version of the URL is used. This will decode any URL parameters, and then when the accepting page pulls parameters off the querystring they are decoded again (which breaks encrypted strings). This is especially painful with the + and %2b and SPACE conversion issues. So it would be nice if the use of decoded URLs was consistent here too - javascript will not decode but non-javascript will decode...
It would be nice if Infragistics could reply with their suggested approach and an overall explanation of this.