Forum Moderators: travelin cat
Spent the best part of a week scratching my head on this one... :-(
The problem is with the search form at my site not submitting when using Safari. It's fine with nearly all other browsers, including Firefox (but not Konqueror).
This uses asp.net and the form uses .net's postback functionality.
The weird thing is it doesn't do it all the time. Here's what I know;
- The problem is that when pressing 'Search' the page does not navigate away from the current page. The progress bar does not show any sign of life.
- The site template is the same on all pages. However on my Mac I can search from the home page, search results page (eg. http://example.org.uk/default.aspx?w=boots), but not from any of the 'detail' pages (eg http://example.org.uk/Productions.aspx?id=323 or http://example.org.uk/Facilities.aspx?id=294 )
- My client (also on OS X Safari 1.3.2) tells me that they get same symptoms as above, plus they can't submit searches when they return to the home page after they've done one (successful) search. I have not seen this behaviour and can't replicate it.
- When the search form doesn't work, neither does the login form or the 'logout' link (only visible when you've logged in).
These also work using postbacks.
Does anyone know of any issues with Safari and postback forms? Or have any other explanation for my nightmares?!
As ever, any help appreciated.
Nick
[edited by: encyclo at 7:55 pm (utc) on Feb. 26, 2007]
[edit reason] examplified, see TOS [webmasterworld.com] [/edit]
I can confirm the bug exists only on the 'detail' pages using Safari Version 2.0.4 (419.3).
I don't have experience with .NET postback forms. The main differences between a working page and a non-working page is the
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="" />value is different and then the 'detail' pages have four additional external javascript calls.
So, it's likely the problem is with one of these two things...
A google search for "safari .net postback bug" brings up one issue where the poster says they solved a problem of Safari "mangling the view state on this one page and only in certain situations" by "serializing the view sate and storing it in the session object."
Beyond that... Dunno. :/
Thanks for your response. I have seen that other post - unfortunately the suggested solution is one that would have an effect on the server load that would scale, and I'm finding it hard to believe that it's necessary to go to such lengths to get .net and Safari talking.
We've tried taking out javascript calls with little success. I'll look more into the differences you highlighted and report back here.
Cheers Gregg
Nick
I don't have experience with .NET postback forms. The main differences between a working page and a non-working page is the <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="" /> value is different
I believe by value you're referring to the long string that represents the viewstate. This is a built in part of .net that's included in all forms by default. It stores everything to do with the user's session, including form data. If this is the problem then I'd expect .net to have a problem with Safari in general. My Google searches have brought up surprisingly little on this.
However one thing we have found that's news to me - if you take that viewstate value (which is Base 64 encoded) from the source, copy it, paste it into the first page that comes up in Google when you do a search for 'Makcoder' to decode it, you get sensible data if the source you were taking it from was Internet Explorer or Mozilla. Do the same thing from Safari, and it looks like the viewstate data has been mashed up.
It looks to me like Safari indeed has a problem with these strings and corrupts them. But why does it only effect some pages, and what can be done to resolve it, other than what that guy suggested in that post Gregg pointed out (which would slow down the site for every browser and incurr crazy server load)?!
and then the 'detail' pages have four additional external javascript calls.
We've tried removing these. It doesn't help unfortunately.
Nick
which would slow down the site for every browser and incurr crazy server load
Can you just detect the Safari browser and only store the viewstate server side for those users?
Another interesting find: if you use the debug menu in Safari and change the useragent to IE, the whole site works fine. It is like IIS is making an exception in the way it handles Safari (based on UserAgent detected), but Safari itself rejects that exception!
The case continues....
if you use the debug menu in Safari and change the useragent to IE, the whole site works fine
Very interesting. Why would .NET send something different to Safari if what it sends to IE is already working? I'll keep my "if you don't have anything nice to say" theory to myself. :/
