Nick autoupdates in IE only

[Uruloke]

PFC Version: 1.2
PHP Version: 5

Shared or Dedicated Hosting: Shared
Link to your website: http://chat.tolkienguide.com

Are you able to reproduce the issue on the official demo (http://www.phpfreechat.net/demo)? Not quite. Since I am using the line of code

$params["nick"] = "guest".rand(1,1000); // setup the intitial nickname

that you have in your index.php included with the 1.2 release, though, I am assuming you can recreate it as well. (I put that line of code into demo2_simple_with_params.php, turned off frozen nick, and was able to reproduce it.)

Have you set any parameters? If so, please include your code.

See above. demo2 with the randomizer in the nick param reproduces it.

What is the issue you are experiencing in detail?

When launching demo2 (with randomized guest nick) in IE7, pretty much every time the AJAX refreshes the page, I get a new nick. This problem does not occur in Firefox 3 or Safari. I have left the nick randomizer turned on in my site for now if you want to see it happening there, but you should be able to reproduce using demo2 with the two param changes.


Are you seeing any error messages, such as javascript errors?

No, just getting kicked off by the noflood bot after a few moments.

Note that I do understand the workarounds and will continue with my XOOPS module integration, but wanted to point this out to you so that hopefully it could be fixed.

[OldWolf]

Are you using frozen nick?

[Uruloke]

Hi OldWolf,

for my website implementation, I am allowing the user to set the nick rather than using the autogenerated guest nickname now, to avoid this problem. I suppose I could also set the nicks to be frozen. It just didn't occur to me that all of the parameters are re-set every time the AJAX refreshes the page - doesn't seem like efficient use of bandwidth! UPDATE: I just checked, and the changing nickname does occur with frozen nick set.

Another bug I am now seeing intermittently - for some users, every line they type in is displayed twice on their chat window (not others' though). If someone else has seen this I would appreciate feedback, but I expect I can track it down myself given enough time to dig through the code some more.

[OldWolf]

It may be inefficient, but necessary. Consider when you're setting a user's nickname. If you decided you wanted to change the user's nick name (say, for example, on logout of your user management system), you'd want to be able to set the new nickname. If the parameter isn't checked, it can't accomplish this... so basically whatever you set when they first logged in would be what you were stuck with. That wouldn't be very useful.

It's also important to note two things:
1. It doesn't effect bandwidth (CPU processing time would be slightly effected, but in such a minuscule way it wouldn't effect you unless you had a veru large number of users), since the parameters are handled on the server side:
Request to server -> Server received request, checks values, returns new data -> Client receives new data, handles it, and returns to the first step.
2. Not all parameters are updated each time. Many are cached that are unlikely to change, and require a "/rehash" to update. This would be impractical for usernames though.

And the reason I asked about frozen_nick, frozen_nick will cause the name to continuously update. I know this might sound backwards at first, but the phrase "frozen nick" is with reference to the user, not the server. So if frozen nick is true, the user can't change their name, so the server relies on the nick parameter you have set, and continues to update it.

With frozen nick set to false, the server provides the user with whatever initial nick you give (or they input, in the case of an empty nick string), and then it relies on it's stored session data to keep the data up to date, allowing the user to change it themselves (but changing the parameters would do nothing).

Does that make sense?

So to stop the constantly changing nick, you should need to only set frozen_nick to FALSE.