Created attachment 8577608 [details] Screenshot_2015-03-14-14-36-56highlight.png User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150222232811 Steps to reproduce: 1, go to https://www.hmailserver.com/forum/viewforum.php?f=7 2, Choose any thread and tap into it using the date/time of the "last post" line (problem does also happen with choosing thread title but with the date/time option its quicker to reproduce). See screenshot "Screenshot_2015-03-14-14-36-56highlight.png" for example. 3, Entry into the thread may go in ok. You may then use BACK button to go back to the forum index menu (or tap the thread title at the top of the page to retuen to the forum index again), and then choose a thread to enter in again by the same method. Actual results: Upon tapping to enter the thread the error "SSL_error_rx_record_too_long" (see screenshot) is displayed. When this happens, simply tapping TRY AGAIN then enters the thread as required. NOTE: The "SSL_error_rx_record_too_long" message SOMETIMES displays the first time you enter a thread, sometimes, its after 2 or 3 reads of threads - there is nothing definitive of how and when it does it (except you can guarantee it will within a few reads of different threads and it happens too regularly). Often, if you see the delay (before displaying the error) entering the chosen thread soon enough and you REFRESH the index page, this then allows you to choose and go into a thread (at least for the first retry) ok; almost as if it clears some sort of cache. But then it becomes guess work as to how many you can look in and browse before the message comes back. Expected results: It should enter the thread as requested without a problem (as you will see it does for the first time you try). As it SOMETIMES goes in to the thread without a problem, and then sometimes it doesnt (ie, you can hgo in, read, back out and try to go in again), and as it is the same forum/site (no change, and therefore using the same SSL connection all the time), it make no sense that 'sometimes it works, sometimes it doesnt'. Note: IF I browse this same forum with Android stock Browser, or Chrome, this problem NEVER occurs and the experience is fast and trouble free. Also note: this forum/site does not have a 'desktop' version that can be called upon over the displayed 'mobile version': it seems ot is the same provision of gui just with the layout modified dependant on browser type viewing it. (ie, clicking 'display desktop version' doesnt make a difference to the layout or connection.) I think this problem is not just specific to this site I am using but I reference it as an example to demonstrate the problem.
Comment on attachment 8577608 [details] Screenshot_2015-03-14-14-36-56highlight.png Example of where to enter a thread
Further information: FIREFOX DESKTOP version NEVER has this problem. It is ONLY with the Android version (despite being from the same site)
Loaded 20 forum posts without issue on Firefox for Android running on a Galaxy S5. I also attempted to reproduce on desktop with a mobile view port and Fennec user agent. Neither reproduced the issue.
You running v36? Any explanation or suggestions as to why yours is ok and mine isnt? (Im on S3 mini android 4.1.2) As I say it doesnt happen with the stock browser or an PC desktop browser (currently on v36)
Firefox 36 and 39. Testing on desktop with a mobile user agent and viewport is a valid thing to check. Sites will send different code to different browsers.
OS: Windows 7 → Android
Hardware: x86_64 → ARM
Perhaps its ACTUAL mobile testing that's required.
Ok, an update: So as to promote a faster response and solution, I also contacted the website admin of the link and told them about the problem too. He acknowledged what i reported (without rejection). Yesterday he completely changed the hosting: server OS (from windows to Ubuntu), versions of software (PHP and the PHPBBS), the database holding the data and even the online host provider. Then he informed me to test. After some hammer time testing for the problem I have no longer seen the error. CONCLUSION: It seems therefore that the cause of the problem was with the website (as the error suggests in its text). HOWEVER it does show that the error DID exist and that my Firefox did determine and respond to the case of it happening. And the fact that Kevin's testing DIDNT uncover the problem (now known to be definitely in existence at website level and not end-client browser/system level) shows that the testing platform he used was not a like-for-like test with my platform (otherwise he too would have seen the error).
Server from comment 0 is completely different now. To be clear I tested on multiple devices inducing desktop Firefox and Firefox for Android.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.