This document describes the bugs known to exist in the Openwave® SDK 4.1 that are considered to be most important to application developers. If you discover a bug not listed here, please report the bug to our Developer Support Team.
Pressing the F12 key or Choosing Clear Cache from the Edit Menu of the Simulator 4.1 causes the cache and variables to be flushed for the Mobile Browser and reloads the Home Page, but does not result in the history stack or memory stack being cleared. Workaround: From the Browser Menu choose option 6> Advanced and then option 6> Restart Mobile Browser. This will be addressed in a future release of the Simulator .
When running the Simulator 4.1 in HTTP Direct mode on Windows2000, HTTP Redirects (status 301 and 302) may not work. The Simulator 4.1 is not supported on Windows2000.
Accessing files via a file:// URL with the Simulator version 4.1 on a
Windows2000 machine may result in an "Unsupported Content Type" error. The
Simulator 4.1 is not supported on Windows2000.
If you enter a password-protected URL in the Simulator's "Go:" field, the Simulator will navigate to the home deck instead of the requested URL after you enter the username/password. If you re-request the URL, the Simulator will navigate to it. Solution: This only happens the first time. After the username/password is authenticated, re-enter the URL in the "Go:" field and the Simulator will navigate to the appropriate card.
The WinInet.dll that ships with the SDK 4.1 has a known bug that prevents proper resolution of localhost when there is no active network connection. Microsoft does not permit any other version of WinInet.dll for inclusion in non-Microsoft products. Solution: The only way to upgrade WinInet.dll to fix this bug is to install Internet Explorer 5.0 or higher.
The addCookie method in both Perl and the new PDCDigetsUtils will will only allow you to add one cookie. If addCookie is called more than once, only the last call will stick. All previous Set-Cookie headers will be over-written. Solution: concatinate all of your cookies into one string.
The Simulator version 4.1 will report a MAX_PDU of 2984 bytes in the HTTP Headers. The MAX_PDU for the Mobile Browser version 4.1 in shipping devices is 2000 bytes.
The 4.1 Simulator will not display Korean content. The Simulator will report "Unsupported Content Type." Korean content can be displayed successfully by using the 4.0 Simulator.
The MTP1 phone configuration devliers a Device ID of "MTP1" in the USER_AGENT HTTP header. This is not the same device ID that the real Motorola Timeport L7389 phones deliver. The correct Device ID is MOT-CB. Workaround: Open the file MTP1.pho in a text editor (the file is located in the configs directory of your SDK 4.1 installation). Near the end of the file is a line which reads
DEVICEID MTP1
This should be changed to read
DEVICEID MOT-CB
SDK Libraries
On Windows2000, the SendNtfn tool may crash if both Use Certificate Info and Require Certificate check boxes are selected. At this time, the SDK 4.1 is not supported on Windows2000.
Mobile Browser 4.1 / WML 1.1
If you put a variable before a $ character entity ($ or $$), the browser
renders the value of the variable, then name of the variable, and then the $
rather than simply the variable value, and a single $.
For example:
Renders on the browser as:
goo $myvar $
This is not an issue on the 3.x browser, and is not a problem as long as
there is not a variable preceeding the $ character entity.
Workaround: None
If you include "$$" in a URL attribute value (to insert a literal "$" character into the URL string), the Simulator will report an "invalid variable" error. Solution: Per the WML Specification, you should use the escape string "%24" instead of "$$" in URL strings.
If you include both a format string and a maxlength string in an <input> element and the format string specifies the number of characters, it will take precedence. For example, in the following deck, a user may enter only 5 characters despite the fact that the maxlength is set to 8.
<wml>
<card>
<do type="accept">
<go href="../next.wml"../>
</do>
<p>
Enter a number
<input name="NUM" format="NNNNN"
maxlength="8"../>
</p>
</card>
</wml>
However, if you do not specify a fixed number of characters in your format string, maxlength will take effect. This is illustrated in the following deck which will allow the user to enter no more than 5 characters.
<wml>
<card>
<do type="accept">
<go href="../next.wml"../>
</do>
<p>
Enter a number
<input name="NUM" format="N*N"
maxlength="8"../>
</p>
</card>
</wml>
The Mobile Browser v4.1.16 has known issues when rendering cards that contain
both <do type="accept"> elements and <option
onpick="href"../> elements. This version of the Mobile Browser is known
to be in the Motorola L7389 currently shipping from Bell South, and in the Motorola
Accompli A6188. Motorola is currently working on making a new version of the Mobile
Browser available for these devices.
The Mobile Browser v4.1.16 through version 4.1.21 does not support using
Basic Authentication in conjuction with HTTP POST when connecting through a
non-Openwave WAP Gateway.
Workaround: Either use application level authentication (more secure anyway) or
don't use method="post"
Mobile Access Gateway Server
The Simulator 4.1, when connecting to an Mobile Access Gateway version 4.2 or lower may incorrectly report "Unsupported Content Type" when trying to access Simplified Chinese content (GB2312). This problem is not seen with the Mobile Access Gateway version 4.3 and above.
Basic Authentication does not work when a device with the Mobile Browser 4.1.x connects to the Mobile Access Gateway version 4.2.2. This problem is resolved in the Mobile Access Gateway version 4.2.2.2, and does not affect
handsets with the version 3.x Mobile Browser
When you POST data through an Mobile Access Gateway Server, the Mobile Access Gateway transcodes the data from the character set of the device to the character set of the application server. When this transcoding takes place, the Mobile Access Gateway includes the charset parameter with the content type of the posted data, for example:
application/x-www-form-urlencoded;charset=UTF-8
The charset parameter is compliant with the HTTP spec, however, neither ASP nor the Java Servlet classes recognizes it, and the result is that neither environment can correctly build the appropriate form objects. As a workaround, you can access the post data from the input stream:
// First read off the input stream as follows
int contentLength = req.getContentLength();
byte[] b = new byte[contentLength];
int result;
int totalRead = 0;
try {
result = in.readLine(b, 0, b.length);
while (result != -1) {
totalRead += result;
result = in.readLine(b, totalRead,
buffsize);
}
} catch (IOException ioe) {
// Ignore, it's probably from EOF
}
SDK Documentation and Sample Code
In the WML 1.1 Language Reference that ships with the 4.1 SDK the explanation of "prev" requires correction. In the list for the <type> attribute of the <do> element the explanation for "prev" should read:
prev Navigates to previous card by invoking PREV mechanism from current card.
The WMLScript Reference Chapter 8 incorrectly refers to the method url.escapeString(string)
The correct syntax is URL.escapeString(string)
In the HDML List Manger example which is hosted on the Openwave Developer website does not function properly with the SDK 4.1. It works as expected with the SDK version 3.2, for which it is designed.
In the HTML documentation that ships with the SDK, there are three images missing from the SDK Developer's Guide.
The <access> element is missing from the second deck in Figure 2-8 of Chapter 2
of the SDK Devleoper's Guide. The code displayed in the card should begin with:
The WhereAmI.cgi example reverses the values of Latitude and Longitude when presenting them in the WML Deck:
Workaround: Edit the WhereAmI.cgi file and swap the values in the line
$locDec = $locDec. "Latitude Longitude = ";
to read $locDec = $locDec. "Longitude Latitude =";
The crusty.cgi example cannot match a zip code because it looks for a non-existent file, "locations.txt" rather than
the correct file "locations.dat"
Workaround:
Edit the crusty.cgi file to change the line $locFname =
"./locations.txt"; to $locFname = "./locations.dat";