[IUG] long search strings and IE
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I have a call in to the helpdesk, but thought I'd see if someone on the
list might know the answer:
We have an issue where a very long search string in the OPAC (60 words)
does the search but when you click on the link on the browse screen to go
to the bib record, it gives an error.
I have ascertained that the error is because Internet Explorer is
truncating the looooooong URL Innovative creates for the browse link by
appending the search string (not to mention all the spaces changed to
Interestingly enough, Firefox seems to not show this bad behavior and goes
to the bib records just fine. The link url is just as long and ugly, it
just doesn't truncate it like IE.
Is there anything I need to put into my html maybe to keep IE from the
truncation or is there a Millennium setting that can be turned off to not
retain the double (and sometimes triple) search history?
Unfortunately I can't show you the search or our catalog because of
firewall and corporate policies, but I'm hoping someone has an idea. We
are on the latest release of the software but are using older html.
GM Information Research
cell phone: 517-403-4622
email: kathy dot koch at gm dot com
"If you would persuade, you must appeal to interest rather than intellect
." ~Benjamin Franklin
Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--- StripMime Report -- processed MIME parts ---
text/plain (text body -- kept)