java servlets, javascript and firefox 3.6

[Guest]

I have been told on a firefox support forum to ask in a java forum
(although I'm still convinced it is a firefox problem).

I had an arrangement like this, which has been working for 5 years (and
still works with old versions of firefox).

There is a frameset (on host a port 80).
The frameset contains two frames.
Its HEAD defines a number of javascript functions,
The top frame (a page on host a port 80) contains a form.

The action of the form is a java servlet (potentially running on a
different host, can be host b port 8080, or host a port 8080 which for
what the browser is concerned counts as a different host)

The servlet writes to the bottom frame a short message and some
javascript code which invokes functions in the frameset HEAD (like e.g.
parent.changeItem(...)) which modify the content of the form in the top
frame.

The javascript code and the user user.js contain appropriate provisions
to give permissions to update the form (.codebase_principal_support...).

All this worked perfectly. It ceased working in firefox 3.6 (i.e. when I
upgraded the CLIENT machine to suse linux 11.3)

The javascript generated in the bottom frame gives an error like
"parent.changeItem is not a function" ... it looks like the DOM of the
frameset is not yet known when the bottom frame is executed.

This does NOT occur if such javascript is present in a static html page
in the bottom frame, in a static html page loaded clicking an url in the
bottom page, or is generated by a CGI.

It occurs only when the CONTENT of the bottom frame is generated by the
java servlet. WHY SHOULD THE BROWSER MAKE ANY DIFFERENCE ON WHAT IS
GENERATING THE CONTENT ? A remote servlet, or a CGI, or an HTML should
be equivalent !


My current workaround is that the servlet stores the javascript in a
temporary html file on http server a, and issues a sendRedirect.

This way the error does not occur. As if it were a static html file or
the output of a CGI.

BUT WHY IS OUTPUT OF A JAVA SERVLET DIFFERENT ?

 

[Paul Cager]

I have been told on a firefox support forum to ask in a java forum
(although I'm still convinced it is a firefox problem). ....
It occurs only when the CONTENT of the bottom frame is generated by the
java servlet. WHY SHOULD THE BROWSER MAKE ANY DIFFERENCE ON WHAT IS
GENERATING THE CONTENT ?  A remote servlet, or a CGI, or an HTML should
be equivalent !

Agreed the browser shouldn't care if the content was generated by
servlet or CGI etc.

If you haven't already, it might be worth using Fiddler (http://
www.fiddler2.com/fiddler2/) or similar to look at the response
returned by the servlet and static page. This is all guesswork, but
there might be something "odd" in the headers returned by the servlet
for example, or maybe the servlet issues a redirection you are not
expecting. Or maybe the browser doesn't like the look of the servlet's
URL. Or could the content-type be different/missing?

If there's nothing obviously wrong you could try changing the
servlet's URL to look like a static page, then try fiddling the
headers returned by the servlet and so on.

 

[markspace]

It occurs only when the CONTENT of the bottom frame is generated by the
java servlet. WHY SHOULD THE BROWSER MAKE ANY DIFFERENCE ON WHAT IS
GENERATING THE CONTENT ? A remote servlet, or a CGI, or an HTML should
be equivalent !

There's a user-agent field in most GET or PUT HTTP commands that
identifies what browser (if any) you are running. It is possible for a
servlet (or some library you installed) to sniff that user-agent field
and generate different output depending on what value it sees.

I agree with Paul. Get a packet sniffer of some sort and verify the
output of the server. Better, get HttpUnit and verify the output
doesn't change as part of the regular system/integration testing.
You'll need to sniff the user-agent string out of Firefox and use that
exact string in one of the HttpUnit tests.

 

[Mayeul]

There is a frameset (on host a port 80).
The frameset contains two frames.
Its HEAD defines a number of javascript functions,
The top frame (a page on host a port 80) contains a form.

The action of the form is a java servlet (potentially running on a
different host, can be host b port 8080, or host a port 8080 which for
what the browser is concerned counts as a different host)

Isn't that supposed to violate the same origin policy?

It looks like it with my quick tests between http:// and file:, or file:
and file: in different parent directories.

Check https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript
That's supposed to predate Firefox though.

 

[Guest]

Isn't that supposed to violate the same origin policy?

Yes it is, but can be bypassed setting in user.js
user_pref("signed.applets.codebase_principal_support", true);

This was done 5 years ago on the old browser, and propagated to the new
one. It is the first thing I checked, and it is NOT the problem.