Viewed   70 times

Using Google Chrome, I'm seemingly losing/corrupting session data when navigating between pages (PHP 5.0.4, Apache 2.0.54). The website works perfectly fine in IE7/8, Firefox, Safari & Opera. The issue is only with Google Chrome.

I narrowed down the problem. I'm using search friendly URL's, and hiding my front controller (index.php) via a .htaccess file. So the URL looks like: Here's the .htaccess file contents:

Options +FollowSymlinks 
RewriteEngine on
#allow cool urls 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^(.*) index.php [L] 
#allow to have Url without index.php 

If I remove the .htaccess file, and expose the front controller in the URL:, Chrome works perfectly fine.

Any thoughts ideas? I'm thinking it's some kind of problem with how Chrome identifies what cookie to use and send to the server? This happens in Chrome 4 & 5. Thanks!



I had the same issue, and to fix it I only had to create a favicon.ico and place it in the webroot - otherwise I could see using Fiddler that a 404 resulted for this with every page request from Chrome (despite me not actually linking to a favicon in the page markup).

In my mind this is clearly a bug in Chrome, as the lack of a favicon should have no bearing on session data.

Saturday, December 10, 2022

OK. I've triple-tested this and I am 100% sure that it is being caused by my anti-virus (ESET NOD32 ANTIVIRUS 5).

Whenever I disable the Real-Time protection, the issue disappears. Today, I left the Real-Time protection off for 6-7 hours and the issue never occurred.

A few moments ago, I switched it back on, only for the problem to surface within a minute.

Over the course of the last 24 hours, I have switched the Real-Time protection on and off again, just to be sure. Each time - the result has been the same.

Update: I have come across another developer who had the exact same problem with the Real-Time protection on his Kaspersky anti-virus. He disabled it and the problem went away. i.e. This issue doesn't seem to be limited to ESET.

Friday, August 26, 2022

Chrome wants to focus on a control that is required but still empty so that it can pop up the message 'Please fill out this field'. However, if the control is hidden at the point that Chrome wants to pop up the message, that is at the time of form submission, Chrome can't focus on the control because it is hidden, therefore the form won't submit.

So, to get around the problem, when a control is hidden by javascript, we also must remove the 'required' attribute from that control.

Wednesday, August 31, 2022

At this point, too many browsers are pretending to be Chrome in order to ride on its popularity as well as combating abuse of browser detection for a simple match for "Chrome" to be effective anymore. I would recommend feature detection going forward, but Chrome (and WebKit/Blink in general) is notorious for lying to feature detection mechanisms as well, so even that isn't as great as it's cracked up to be anymore either.

I can only recommend staying on top of things by comparing its known UA strings with those of other browsers through third-party sites, and creating patterns from there. How you do this depends entirely on the strings themselves. Just keep in mind that due to the nature of browsers, and UA strings, there can never be a "reliable" regular expression for matching them.

In PHP, the relevant server var is $_SERVER['HTTP_USER_AGENT'].

Friday, November 4, 2022

Currently, this is not possible.

You can use multiple profiles in Google Chrome, though. Read the instructions here.

Thursday, October 27, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :