Many thank's for your responses !
1) using window.location.href
I understand that's the most straightforward approach but let me
explain why it's not accessible out-of-the box for us. Our server-side
technology is JSF (Java Server Faces) and in JSF there's no one-to-one
mapping between a URL and corresponding content (meaning same URL may
return different content, according to the previous state). In JSF
navigation rules are specified on the server-side and not on the page
itself, like it's usually done with "href" of links and "action" of
forms. For example, when one requests
http://host/applicarion/sample.jsf and view the source - all "action"
attributes of all the forms on the page are targeted to the page itself
(
http://host/applicarion/sample.jsf) so when any form is submitted -
you're "kind of" requesting the same page but when request is processed
on the serfer side and navigation rules are applied (according to
faces-config.xml residing on the server) - the corresponding content is
sent back. It may be the same page (if navigation rules say so) or a
new page - one really doesn't know until response comes back.
So for my situation I can't just return a URL of the new page from the
server as it's out of my control - JSF engine provides us with response
to send back to the browser. But you, guys, still got me thinking that
may be I can hold the whole response (whatever page it is coming from,
I simply don't know that) using in-memory buffer and generate a unique
URL for it and still redirect the browser to this unique URL (using
window.location) which will flush in-memory buffer to response .. So
far this seems to be the way according to your responses.
2) Using frames
I'm not sure. I mean, our Ajax support for JSF applications is
home-made and one of it's strengths is that any JSF application is made
Ajax-capable (all forms are submitted by Ajax and according to the
response the DOM is either updated or re-written completely, as was
described in my first post) without modifying any page or requesting
any special markup. But I'll surely keep that in mind !
3) Proving *there is* a problem in Firefox
I would be glad if that was the case as document.open()/write()/close()
is obviously the easiest way to implement document replace. So I wanted
to hear what would people say - does it seem logical to them that it
should work or we shouldn't rely on this behavior. So far nobody seems
100% convinced that it should work. But I'll try providing a simple
use-case demonstrating how it breaks and will post it here and to
Mozilla forum as well. Who knows - may be someone from Firefox team
will respond "It's a bug which will be fixed in the next version" and
then we'll simply go back to the old way with
document.open()/write()/close(). As for the reason why it does work for
someone else and doesn't work for us - I guess external JavaScript
files we're using may have something to do with that (we have
Prototype, script.aculo.us and then some ..)
Ok, again, thank's a lot for your ideas, guys. I'll be working on 1)
and 3) and will let you know as soon as possible. But till then - any
new ideas are still welcome, of course !
