Bob Grossman

Ranch Hand
+ Follow
since Dec 18, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Bob Grossman

Never mind ... a bad for loop was preventing the tab characters from being written to the document. All is good now. Sorry to waste your time.
I am using Javascript to write data in the form of nested arrays to another text document or browser window.



I want the output to look something like this:

[   'Text level 1',
   [   'Text level 2',
       [   'Text level 3'
       ],
       [   'More text level 3',
       ]
   ]
]

What it appears as is this:

[   'Text level 1',
[   'Text level 2',
[   'Text level 3'
],
[   'More text level 3',
]
]
]
]

which is much less readable! All the leading tab characters are deleted, although tab characters that follow non-whitespace characters are not deleted. (I should mention, I output <pre> and </pre> at the beginning and the end of the child document.) I tried outputting the tab characters as \t and , but I did not see any difference. I'm using the latest version of Safari for Mac.

Any suggestions? Is the problem browser-specific? Is there a Javascript method that would tell the browser to output the leading tab characters?

For those of you following this thread: We recently switched from http to https. Under https, the browser and server use certain SSL cipher protocols to communicate. Apparently, there's a bug associated with the AES ciphers. Changing the server configuration to remove AES/GCM from the list of acceptable ciphers eliminated the problem.

We also found that among the Mac browsers, although Safari and Chrome chose the AES protocol if it was available, and thereby manifested the bug, Firefox did not.

I still don't know what property of a URI causes the AES bug to manifest, but I guess I don't need to know anymore.

Thanks for your willingness to help.
5 years ago
JSP

Stefan Evans wrote:Hi Bob,

Paul suggested using POST rather than GET, so that you don't need to encode your url encoding.
Your response was that you were using POST - which you are. The parameters are sent via xmlHttp.send() on line 16.

So that would suggest you don't need to have the call to encodeURIComponent on line 2 of your source. Maybe that might be a source of trouble?
If the send method will encode your parameters for you, then encoding things twice might be a potential issue :-)



Thanks for your suggestion. I don't see how I can forego encoding. The response that I am sending definitely contains = symbols and may contain & symbols; if I don't encode it, I imagine that the server will try to split up the one parameter into multiple ones, won't it? As a simplified example, if I want to send the value "a&b=c" for parameter p, and I don't encode, I'll be sending "p=a&b=c". and won't the server interpret that as parameter p having a value of "a" and parameter b having a value of "c"?

As fo the rest of your suggestion, I don't understand what I would learn from your suggestion. I know exactly where the NPE occurs, and it doesn't have anything to do with the Javascript.
5 years ago
JSP

Paul Clapham wrote:
First, you seem to have a workaround which prevents the NPEs from occurring, so maybe you should just go with that.



I would agree, except that because I have no idea what is triggering the error, the workaround may work for this response, but then cause another response that would ordinarily go through, not to go through! So I'm not happy with my workaround.

5 years ago
JSP
I don't think the forum changed what I wrote. In XML without return characters, there are many instances of ><, that is, a greater than sign to close one element, and a less than sign to open the next element. I can insert a return character after each element by doing a global replacement of >< with >\n<, like this:



And when I do that, the new string does not trigger the NPE. As I said, this is a bizarre bug. Seemingly trivial changes in the URI make a difference in whether the NPE is triggered.

As for GET vs. POST, we already use POST. See line 11 of the first block of code in my very first post in this topic.
5 years ago
JSP
This phenomenon is completely reproducible on our installation.
I load a chemical drawing into a third-party program.
I press Submit, and the third-party program creates an XML representation of the drawing.
I use AJAX to send the XML to the server for analysis.
When I load a particular structure into the program and submit it, I get the NullPointerException.
If I change the appearance of the structure somewhat, so that some of the coordinates encoded in the XML change, the submission may go through.
I have found two drawings so far that fail to submit. The one whose XML is below is easier to reproduce than the other one; the other one, I always
have to draw in a very particular way to trigger the NPE, and it's hard to do it right every time.

Here is a value for toSend that induces the NullPointerException. Sorry, it contains no return characters, even before it is encoded.



If I convert all instances of >< to >\n< before encoding and submitting, I don't get the NPE.

There's nothing interesting on the JSP page before the line that triggers the NPE. Here it is:



The two included pages, edJava.jsp.h and rxnCondsJava.jsp.h:



When the bug is not triggered, the log says:

INFO: answerJava.jsp.h: about to getParameter().
answerJava.jsp.h: did getParameter().



When the bug is triggered, the log says:

INFO: answerJava.jsp.h: about to getParameter().
java.lang.NullPointerException



I did not experience this problem until we moved to a new, Javascript-based, structure-drawing program. The previous one was a Java applet,
and you probably know more horror stories than I do about Java applets. One difference between the previous and the current structure-drawing
programs is that the current one does not put return characters after each XML element, whereas the previous one did. If I add return
characters to the XML above that causes the NPE, I do not get an NPE. But that doesn't mean that I would never get an NPE with some
different XML that did contain return characters.

Finally, I appreciate your disparagement of the code, but I am not writing it from scratch, and it does indeed date back about 15 years.
I recognize that it could be written more efficiently and in a more maintenance-friendly manner, but I am not in a position to rewrite it.
I am just trying to figure out why on very rare occasions, the code fails.
5 years ago
JSP

Bear Bibeault wrote:

You have checked the Java file for line 409? (Not the JSP file, whose line numbers are meaningless.)



Yes, answerframe_jsp.java, line 409.
5 years ago
JSP

Bear Bibeault wrote:There is no way on Earth that the NPE is caused by that line of code. What makes you think that it is?



Well, for one thing the NPE stack trace reports the line in answerframe_jsp.java that throws the exception, and if I look in that file, the reported line is the one I described. For another, if I print to the log immediately before and after that line, the log shows output from before that line, but not after.
5 years ago
JSP
I'm using AJAX to pass a string from a Javascript application to a Java server page (JSP) for processing. Here's a snippet of the code:



In very rare (I've found two examples so far) but completely reproducible circumstances, certain values of submissionStr cause responseText to come back empty. The log reveals that a NullPointerException is thrown at the second of these two lines from the JSP page:



The log output shows:



There are a number of features of this problem that are mystifying to me. Why would System.arraycopy() throw a NullPointerException at all, and why would it do it only for very particular values of submissionin the URI? Finally, what can I do to fix the problem?
5 years ago
JSP
I have a page that uses Javascript to display an alert when I click on some text. New in Safari 9.0.1 (MacOS El Capitan), the alerts are being truncated by Safari. For example, this code on the page:

alert('Alomerovic, Arnela has an extension of 0.6 days.\nBryan, Lindsey has an extension of 0.3 days.\nBullock, Hannah R. has an extension of 0.25 days.\nCooke, Alexander C. has an extension of .75 days.\nDunlap, John H. has an extension of 1 day.\nEvans, Logan J. has an extension of 0.6 days.\nJEON, HAYCE has an extension of 1 day.\nMcAteer, Jordan P. has an extension of 2.7 days.\nMeredith, Luke T. has an extension of 1.5 days.\nMueller, Rebecca J. has an extension of 1 day.\nNguyen, Thuy N. has an extension of .8 days.\nPaschke, Kimberlyn E. has an extension of 1.0 day.\nTran, Angela has an extension of .5 days.\nWatkins, Benjamin C. has an extension of .5 days.\nWeiss, Blaine E. has an extension of 0.08 days.');

gives rise to this alert:

Alomerovic, Arnela has an extension of 0.6 days.
Bryan, Lindsey has an extension of 0.3 days.
Bullock, Hannah R. has an extension of 0.25 days.
Cooke, Alexander C. has an extension of .75 days.
Dunlap, John H. has an extension of 1 day.
Evans, Logan J. has an extension of 0.6 days.
JEON, HAYCE has an extension of 1 day.
McAteer, Jordan P. has an extension of 2.7 days.
Meredith, Luke T. has an extension of 1.5 days.
Mueller, Rebecca J. has an extension of 1 day.
Nguyen, Thuy N. has an extension o

And this code on the page:

alert('Barnes, Kevin M. has an extension of 1 day.\nBryan, Lindsey has an extension of 0.5 days.\nDunlap, John H. has an extension of 2 days.\nHolland, Emma K. has an extension of 2 days.\nJEON, HAYCE has an extension of 2 days.\nLoya, Edward K. has an extension of 1 day.\nMcAteer, Jordan P. has an extension of 2 days.\nMeredith, Luke T. has an extension of 1 day.\nNguyen, Thuy N. has an extension of 0.7 days.\nNickell, Danielle has an extension of 2 days.\nPaschke, Kimberlyn E. has an extension of 1.5 days.\nThompson, Brandyn L. has an extension of 1 day.\nTran, Angela has an extension of 1.5 days.\nWatkins, Benjamin C. has an extension of .5 days.\nWeiss, Blaine E. has an extension of 0.28 days.\nYu, Samuel S. has an extension of 1.65 days.');

gives rise to this alert:

Barnes, Kevin M. has an extension of 1 day.
Bryan, Lindsey has an extension of 0.5 days.
Dunlap, John H. has an extension of 2 days.
Holland, Emma K. has an extension of 2 days.
JEON, HAYCE has an extension of 2 days.
Loya, Edward K. has an extension of 1 day.
McAteer, Jordan P. has an extension of 2 days.
Meredith, Luke T. has an extension of 1 day.
Nguyen, Thuy N. has an extension of 0.7 days.
Nickell, Danielle has an extension of 2 days.
Paschke, Kimberlyn E. has an extension of 1.5 days.
Tho

There is no scroll bar in the alert window. I'm attaching a screen shot of one of the alerts.

Am I missing a setting somewhere, or is this a bug? I don't observe this behavior in Chrome or Firefox, nor did I observe this behavior in previous versions of Safari.
I agree. The question is, why is it wrong? Can the process of writing the base64 string to a text document cause information to be lost or corrupted?
8 years ago
Because changing the src wasn't working either. Besides, I was originally using SVG to generate the image, so it was as little change as possible to drop in the entire tag in place of the SVG.
8 years ago
I'm experimenting with updating images in a Web page by using AJAX to send new image display options to a Java method on the server. The server generates a Base64-encoded URI for a PNG image and writes it to a JSP Page. AJAX returns this page, I extract the URI from it using standard Javascript string methods, and I use innerHTML to replace the old image (the entire image, not just the src) with the new one.

Sometimes this procedure gives me a ? instead of the image. In fact, in one particular case, I have an image that displays just fine, but if I change an option, then change it back to what it was originally, I get a ?, even though the image (and presumably the URI) hasn't changed.

So here's my question. Is it possible that some, but not all, Base64-encoded strings could become corrupted by being written to a text document, then extracted into a Javascript variable, then parsed with standard Javascript string methods?

I'm using a class called Base64Coder from http://www.source-code.biz to do the encoding into Base64.

Here's the src for the image that displays just fine:

[Edit: ultra-wide Base64 string removed]

And here's what the Java method is returning upon the AJAX request to revert to the original image:

[Edit: ultra-wide Base64 string removed]

Here's the Javascript method I use to update the image:

8 years ago
Ah, my mistake was assuming that the JSP page executes on the client side.

The hidden text is XML that describes a chemical structure. I am displaying XML (SVG) that is the image of said chemical structure. Currently, I have the entire image XML surrounded by ..., calling this method:



where getOrigMol() returns the XML describing the structure. This procedure works, but it requires three actions from the user (click on image, copy highlighted text in popup, close popup) and produces an annoying popup. I thought I had discovered a way around the prohibition on Javascript accessing the client's clipboard. But my brilliant idea is no good after all. Story of my life.
8 years ago
JSP