Hi

I've always been frustrated that the back button only works with HTML drill - you have to go back 2 in the dropdown by the back button for PDF and Excel. I have always assumed this to be the fault of IE in that it should not hold redirects in its back list or there should be a setting to turn this off or on.

However according to this article it's up to the developer to ensure the back button works.

http://www.webmasterworld.com/forum91/2996.htm

I'm no great shakes at html - does anyone know could IBI code their redirects to get the back button to work?

Looking forward to your answers

John

John,

The reason that the back button "does not work" in PDF and Excel outputs is down to the fact that the output is redirected (see redirection settings on your server) and as a result the back button - which issues a javascript go.back() - only backs up to the point at which the redirection took place.

If you click on the down arrow next to the back button you will see the history for that browser window and you can select the second item in the list to take you back to where you want to go.

T

John,

It is not a browser issue, or directly an HTML issue.

When a request for a report is made, you will see a URL something like:
http://server/ibi_apps/WFServlet?......

If it is an HTML request, then a page is returned directly, if PDF/EXCEL the page is 'refreshed' with the URL to retrieve the PDF/EXCEL file, that's the URL with the GETBINARY in it. That is 2 URLs since the original call, not 1.

The only way to control this would be via the server, but a general feeling is that this might be problematic. If the same URL is requested via the Back button, the server could pass control back one level, but what happens if the refresh button is pressed, it can get very complicated, though someone in IB may have the skill to do this effectively.

WebFOCUS is not unique here, many programs/sites suffer the same and it is a general usability issue.

Haven't realy tried this, but what would happen if you specified pdf and/or excel downloads not to be redirected?
You can control that through your mime types file (the mime.wfs) in the webfocus client environemnt. I think it is even accessible through the client console.
Remember to restart tomcat when you're done modifying the mime wfs file directly.

For the record, WF does issue a location.replace(url). Theoretically, this should replace the current history contents of the browser session so that when you click the back button you then get the 2 pages ago. This does work properly when the URL is a HTML file. The actual problem here is that the location.replace() does not work as documented when using IE and the returning document has a content type other than HTML.

If you do GamP's idea and change the mime settings, then the back button will work, but then drill downs will become an issue.

I think the real problem lies with IE here, and not IB. I cannot find any Javascript documentation that says the location.replace(url) will only work with HTML files.

I haven't tried Firefox or any other browser to see if this problem happens with them as well.

quote:

I haven't tried Firefox or any other browser to see if this problem happens with them as well.

I just ran a test with a Firefox PDF Plug-in, and it worked as documented. In other words, the back button brought me back to the starting screen before the PDF file was displayed.

So, I believe this is an IE issue, and not a WebFOCUS issue. Maybe we should all open a thread on an IE developer forum and ask MS to properly support the location.replace() method.

Darryl,

... and the chances of Bill going along with that are .............?

Two hopes - and one of them's Bob!!

T

quote:

Originally posted by Tony A:
Two hopes - and one of them's Bob!!

Nice!

On a side note: Maybe there is hope!

There's points in that article that could apply to some other software vendors I know of

T

Thanks very much to everyone who replied to this. Maybe IE8 will sort this out.

(Or maybe not since Microshaft seems intent on wanting the world to follow its standards while ignoring any worldwide standards itself!)

So close but no cigar.

I was a little bored on the weekend, so I started thinking about this problem. What I tried was to use cookies to store the users navigation for either excel or pdf file. The idea was pretty simple: As a pdf or excel file was generated, the forwarding page would identify the unique url file name and append it to a predefined cookie. When the page was re-loaded (by the back button), if the unique file name was already part of the cookie, then it would remove the name from the cookie and issue window.back(). If the file name did not exist, then it would append the file name to the cookie and allow the page to proceed as normal.

This worked surprisingly well except:
- I could not identify when a forward button was pressed.
- A back button issued on the original page would result in a blank page being presented (because there was no history to go back to).

All in all, I don't know if this behaviour is better or worse the what is currently there.