Jump to content

The ultimate community for Ruby on Rails developers.


Photo

Rails flash notice won't go away in Safari?

flash sessions safari

  • Please log in to reply
43 replies to this topic

#41 james

james

    Guard

  • Members
  • 223 posts
  • LocationLeeds, U.K.

Posted 16 December 2013 - 10:17 AM

So what remains is the "How to get the url to return to?" question

In the

def set_redirect_to

method, grab the url from the current controller/action if it is too late in the process and the current action gives you the action that has already been moved on to in the after filter then use a before_filter to stuff it into another session variable the you can then use in the after filter to set the value for the return_to key.

 

Possibly worth trying 

request.original_url

but as there seems to be an issue with the request object in Safari 7, I am not comfortable with suggesting this as a solution for this particular case.

 

So you might want to try

controller_path

instead. I'm not sure if controller_path will provide any params that are needed though.

 

Hope that makes sense. If you need further help just shout


Programming is just about problem solving!

#42 james

james

    Guard

  • Members
  • 223 posts
  • LocationLeeds, U.K.

Posted 16 December 2013 - 10:41 AM

There is no guarantee of course, that the above will solve the flash message issue, I can only think that it will as it addresses the difference between when it works and when it doesn't work. I still think that it may be down to page caching somehow.

Anyway the above has to be worth a try. If it doesn't fix the issue then I'm sorry, but for once in my life I am totally out of ideas.


Programming is just about problem solving!

#43 joshukraine

joshukraine

    Signalman

  • Members
  • 20 posts

Posted 16 December 2013 - 10:43 AM

Hey James,

 

Thanks for the new input. I'll be sure to try in out and let you know. :)



#44 discopatrick

discopatrick

    Passenger

  • Members
  • 1 posts
  • LocationUK

Posted 13 October 2014 - 06:45 PM

Apologies for "grave digging" the forum - I realise this thread is nearly a year old, but I feel compelled to add my comments, as I'm having exactly the same problem with Safari, and I can't find any other mention of this issue on the web.

 

I'm not sure this is that same issue as yours Signalman, but if it is then I hope this helps. In any case, I hope someone can suggest a solution to my problem on the basis of this new information.

 

I happen to be coding my MVC app in Kohana/PHP, but the principles should be the same.

 

I'm using Safari 7.1. Safari has some special features around the address bar - that is, if you're typing in a URL, a drop down will appear with a "Top Hit" and other items from your "History and Bookmarks".

 

The problem is the URL that Safari deems to be the "Top Hit" is actually loaded in the background.

 

For example, let's say I was viewing my site, looking at the details of a person with an id of 1. The address bar would read:

http://mysite.local/person/details/1

 

Now let's imagine I wanted to view person 2. To do this quickly, I would go to my address bar, position the caret at the end of the URL, and hit the backspace key once, with the intention of typing a 2 to replace the 1. So, for a short moment, the address bar contains this:

http://mysite.local/person/details/

 

Now, because this URL is in my browser history, Safari sees it as the "Top Hit", and displays it as such in the drop down. What Safari doesn't tell you, is that it is also loading that page in the background (I'm not sure why - possibly searching for a favicon.ico?). If you want to prove this is happening, you can add a line of code to your base controller class that logs the URL of the current request to your error log, and then watch the log update as you change the characters in the Safari address bar.

 

In my application, trying to load '/person/details' (without also supplying an id) is considered an error, and so a "flash" message is added to the session, and a redirect takes place. The effect of this is that I sometimes have old messages hanging around in the session that were triggered by Safari's background page request, but haven't yet been displayed/removed from the session. The next time I load a page, even if there were no errors this time, the most recent flash message would still be displayed. This was causing me a lot of confusion!

 

So, what's the solution?

 

Well, the first solution is to do nothing at all, and just hope that Safari users won't directly edit the URL, favouring using the mouse to click their way through the site instead. Depending on the app, this may not be enough.

 

The next thing is to try and differentiate between the requests that the user is making themselves, and those that Safari is doing in the background. I've had a look at the HTTP headers that Safari sends out, and I can't see any difference between the two cases - though I may have missed something.

 

Any other ideas?

 

I really like the technique of using flash messages for providing feedback to the user, and I'd hate to have to drop it just because of this Safari issue.







Also tagged with one or more of these keywords: flash, sessions, safari

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users