sf2 input type date - disable native datepicker

Newer versions of the Google Chrome browser (and perhaps Firefox will follow) implement their own datepicker on input fields with type="date". This seems to be some new fancy HTML5 feature, but correct me if I'm wrong. If you are using jQuery datepicker throughout your whole project for example, you suddenly have two datepickers on that input field.

There is no possibility to turn off the native datepicker with additional attributes. You are left with three solutions to your problem:

1. Use modernizr to detect this feature and only enable jQuery datepickers, if not present:
2. Prevent standard event handling on this kind of input types: which I don't think is a good solution!
3. Render all form fields of type date with type="text" in symfony2. To enable this globally, register a global form theme in your config.yml as described in the Symfony2 documentation. My form theme consists of the following Twig code: This overwrites form_widget_simple and checks for the registered field type before setting it for the input field. If it finds 'date' it is overwritten with 'text'. Very nice and quick solution in my opinion, hope that helps you.

Google Chrome double request session problem

While working on an older PHP project based on a self made framework I noticed strange behaviour when running the project in Chrome. Everything worked fine in all other browsers, no matter, if it was production or development environment.

Each time I logged in the session ID cookie changed. The consequence was, that when trying to reload the page or open other restricted pages the system logged me out.

Even though everthing worked fine on other browsers, I tried to find the bug in the PHP code. I thought I missed something, set wrong headers which Chrome interpreted more strictly than other browsers or something similar. None of that was true. I debugged the code responsible for the session, made sure nothing is going to fall through the cracks. Code that was intended to run once on page execution ran twice, which lead me to the idea, that it's a forwarding/reloading issue.

I checked the $_SERVER array for header information, which differed between browsers. But there was nothing suspicious. REQUEST_URI then revealed the problem: While you would expect only one request to '/' Chrome requested '/favicon.ico' in a second request. This somehow caused a reload with a seperated cookie space, because the reloaded page couldn't read the session cookie and created a new one. I'm not sure what happened in detail but providing a favicon.ico file helped.

I'd like to emphasize that I didn't use a favicon in the HTML, perhaps there is a flag set in the server configuration which is ignored by other browsers.

Hope this helps someone, this took me some time to figure out.