Help debug a random problem

[Technocrat]

I am at a loss and need any advice I can get on what to try next.

 

I have a site where users can edit their profiles. We have about 10K customers. Of those customers about 20 have this issue and I can't figure it out. When they go to the page it acts like it doesn't finish loading. One symptom is when you hover over links the pointer will not change to hand.

 

For me I can login with their account and try different machines and browsers and it works perfectly. I can use Chrome and change the speed and view type still works. I have never actually reproduced the issue.

 

They can hit CTRL+F5, clear cache, try different browsers, different systems, nothing works for them. Today I worked with one person and removed everything from loading on that page except for exactly what was needed. No Google Analytics, no FB pixel, stripped all the JS, and nothing helped. He even tried at his local library and it still happened.

 

I am totally out of ideas. Anyone have any suggestions?

 

Thanks

[mac_gyver]

for one of the users where it doesn't work, hopefully on their computer when it doesn't work, is the copy/pasted html markup of the page in question, valid @ validator.w3.org ?

 

for the last example of a user trying this at a library, is that using a different computer, one at the library, or his same computer, but using a different network/isp?

 

is there anything in common between the users in what is being displayed on the page, such as special html characters (<, >, ', or ") as part of the information being output on the page from their profile?

 

if they disable javascrpt in their browser and visit the page, does the problem still occur?

 

could you have any cookies set due to your development cycle/access to the site that the users don't and it could be causing your attempt at reproducing this to be different from the users?

 

are you using any cookies as part of the process, that if they do/don't exist or with outdated/changed-format/values over various revisions of the software, could affect how the page operates?

Edited November 13, 2015 by mac_gyver

[Technocrat]

Thanks for the reply.

 

 

 

 

for one of the users where it doesn't work, hopefully on their computer when it doesn't work, is the copy/pasted html markup of the page in question, valid @ validator.w3.org ?

I had him check with Chrome inspector and they have no errors at all in the console.  But I could have them try that.  Hopefully they are up to it.  But he tried IE, FireFox and Safari with no luck.  You would think one would render it.

 

for the last example of a user trying this at a library, is that using a different computer, one at the library, or his same computer, but using a different network/isp?  

 

 He was not sure.  That was one my thoughts as well, but the other customers are from other parts of the US, so it seems unlikely but I guess its possible.

 

is there anything in common between the users in what is being displayed on the page, such as special html characters (<, >, ', or ") as part of the information being output on the page from their profile?

 

Nope.

 

if they disable javascrpt in their browser and visit the page, does the problem still occur?

 

Good idea and I will have them try that.  Though it will cripple the page, but it would be good to know if that's part of the issue.

 

could you have any cookies set due to your development cycle/access to the site that the users don't and it could be causing your attempt at reproducing this to be different from the users?

 

I had that thought, so I tried a fresh VM, started up a fresh IE11 on Win10 which is what he is using and right to the site as him and logged in as him.  Worked fine.

 

are you using any cookies as part of the process, that if they do/don't exist or with outdated/changed-format/values over various revisions of the software, could affect how the page operates?

 

No

[QuickOldCar]

It appears to be on their end, could be their internet speed and the item times out, some plugin they use in the browser or maybe an antivirus.

 

Just for a wild guess have them try disabling ipv6 in their network adapter, I've seen issues relating to it.

[mac_gyver]

when this doesn't work, it would be nice if you could get the 'view source' of the page to see if all of it is present, i.e. is the problem that the page isn't being completely sent/received or is it something that's occurring in the browser's rendering of the page.

 

you mentioned that with javascript turned off the page would be crippled, here's a possibility. you have a race condition, that's dependent on the network used to access the site and/or the visitor's computer, having something to do with what the javascript is doing.

 

a common occurrence, that's network speed/timing dependent, is if you are doing ajax requests that make use of session variables, and your main page is also using session variables, and/or you are dynamically producing images that are using session variables, the session data file is locked by each process/request in turn and each later request must wait until the file is release before the session_start() can open the file and return to your php script.

 

if this is what is occurring, and you don't have a problem in your server side code (are you calculating the page generation time on the server and outputting it on the page and/or logging it?) that's causing the page to take a long time to be generated, the way to address this is to do a session_write_close() as soon as you are finished setting/changing any session variables on a page. if all you are doing is reading session variables, you can do the session_write_close() immediately after the session_start().

[Technocrat]

It appears to be on their end, could be their internet speed and the item times out, some plugin they use in the browser or maybe an antivirus.

 

I had the same thought.  He said he has McAfee on his PC, which I ask him to try it disabled.  He tried a fresh install of Firefox.  Also he says the problem also happens on his iPad.

 

Just for a wild guess have them try disabling ipv6 in their network adapter, I've seen issues relating to it.

I might suggest that as well.  I am also going to ask him to try his phone off Wifi also to see if it is his ISP

 

when this doesn't work, it would be nice if you could get the 'view source' of the page to see if all of it is present, i.e. is the problem that the page isn't being completely sent/received or is it something that's occurring in the browser's rendering of the page.

 

I had him already try that.  It renders to the /html and there are no errors in the console or the debug tools.  For fun I ran his profile page through W3C validator and there are some minor "errors" like using the rel attrib and such.  But nothing that I would say should be the cause of the problem.

 

you mentioned that with javascript turned off the page would be crippled, here's a possibility. you have a race condition, that's dependent on the network used to access the site and/or the visitor's computer, having something to do with what the javascript is doing.

 

That was my first thought.  So took the page and took out everything that wasn't absolutely needed.  Then I pulled out anything that runs onload except two things that monitor clicks on two buttons.  Which shouldn't be doing anything because he isn't able to click.

 

 

a common occurrence, that's network speed/timing dependent, is if you are doing ajax requests that make use of session variables, and your main page is also using session variables, and/or you are dynamically producing images that are using session variables, the session data file is locked by each process/request in turn and each later request must wait until the file is release before the session_start() can open the file and return to your php script.

 

if this is what is occurring, and you don't have a problem in your server side code (are you calculating the page generation time on the server and outputting it on the page and/or logging it?) that's causing the page to take a long time to be generated, the way to address this is to do a session_write_close() as soon as you are finished setting/changing any session variables on a page. if all you are doing is reading session variables, you can do the session_write_close() immediately after the session_start().

That's a good thought.  I hadn't considered sessions.  They are running through memcached I think.  I need to check that.  But that could be something.

 

 

 

I also looked through the site logs and found his entries.  Every time he goes to the page everything is either HTTP 200 or 304.  So its serving him content.

[mac_gyver]

For fun I ran his profile page through W3C validator and there are some minor "errors" like using the rel attrib and such.

 

 

does that mean you validated the user's 'view source' from his browser at the time it wasn't working, or was that when you visited the page and it was working? if you are dynamically producing the page, there could be something for this set of users, that's causing the problem, such as data that contains html entities or character-encoded character, url's that need to be url-encoded when output on the page, or even data that's longer then the database field it's being stored in and it has been truncated.

 

one characteristic that may be common to all the browsers/computers/networks where any one of these users has tried or could be a common thing between all the different uses with the problem, is that they may be accessing the web in such a way (proxy server) that a piece of information in the request is missing or not as expected. and the request for the web page could contain all the expected information, but media requests may not (i'm thanking back to AOL, where the requests for web pages and the requests for media on a web page could come from different ip addresses.)

 

are you doing anything in a .htaccess file, such as trying to use the HTTP_REFERER to control access, or in your code trying to get and use their ip address making use of any of the HTTP_xxxxxxx headers? something like this in a .htaccess file or the code, could also account for why when you are logged in as them that you cannot reproduce the problem (i'm assuming you are actually using their credentials, rather than having an admin override, because an override may not be producing the exact same conditions.)

Edited November 14, 2015 by mac_gyver

[Technocrat]

No I logged in as him, view source and ran it through.  So in my mind that sort of eliminates at least his user account having something strange.  Plus where he is stuck is the very first thing after making an account.  So his entire profile is blank at that point other than his name.  I have tried both session overriding and changing his password to mine and logging in.  Both results were the same.

 

That's been a thought I have had.  But again he claims to have tried it from the library and even sent me a video himself on the page from their.  Though it is possible that his house and library are on the same ISP.  Thats why I would like him to try it on his phone with no WiFi.

 

No .htaccess changes other than a url rewrite back to index.php

 

Thanks again for all the ideas.  I am pretty much grasping at straws at this point.  If those couple of people weren't so upset and vocal about it I would just push them off and take the loss.