667992 - Rasahim Michlol 3 site doesn't work with Firefox 5 although it used to work with previous versions

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[reuven]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

Entered the site
https://rashim.sce.ac.il/michlol3/TeacherPortalWap/Pm_Login.aspx


Actual results:

After I.D. number, username and password, the "enter" button does not do anything.


Expected results:

The "enter" button should let me enter the site.

Note: I had an automatic upgrade to Firefox 5 and after it I couldn't use this site. I downloaded a Firefox 4 version in a separate directory, only for using this site.

Comment 1

[reuven]

I had an automatic upgrade to Firefox 5 and after it I couldn't use this site. I downloaded a Firefox 4 version in a separate directory, only for using this site.

Comment 2

[Mardeg]

From https://rashim.sce.ac.il/Michlol3/WebResource.axd?d=HA6h03uxRlmAZoPgFLMNE09U_T5qTW__B6NowCpkF3rXdJSGm05U3et4RuinsqX45EiPCdbXEoOeRC8P-KqH6PQQfbj3m23eN52evtVZ0aYEP0v264JfFPJKRK6BNLFGI6MoVVUYihFh_DAcwHCA5nxV_0y6ZyDeVR3txfa97aBr6qGr0&t=633437825900000000
There is the following browser detection code:
_1.IsGecko=function(){
return (window.netscape&&!window.opera);
};
The code on the site needs to be corrected by the authors, confirming Tech Evangelism.

Comment 3

[Tomer Cohen :tomer]

I can confirm the same issue happening on other sites that use that system as well. 

Does the behavior of window.netscape changed in the recent Firefox release?

Comment 4

[Tomer Cohen :tomer]

Manufacturer site: http://www.rashim.co.il/RashimSite/

Contact page: http://www.rashim.co.il/RashimSite/Default.aspx?Contact

[e-mail]

I am about to contact them. Will inform you of any progress.

Comment 5

[Tomer Cohen :tomer]

I've asked some Greasemonkey/JetPack magicians for scripted spells. It could be faster than asking the manufacturer to update the application and asking every institute to update their sites with the new version.

Comment 6

[Yehuda]

I checked the code in comment #2 and it looks like it still return 'true' in Firefox 5. My guess is that the code got broken in another area, but I can't proceed without a valid username and password with which I can access the site.

Comment 7

[reuven]

(In reply to comment #6)
> I checked the code in comment #2 and it looks like it still return 'true' in
> Firefox 5. My guess is that the code got broken in another area, but I can't
> proceed without a valid username and password with which I can access the
> site.

I can give you mine. Can I write you directly to your gmail ?

Comment 8

[Yehuda]

(In reply to comment #7)

> I can give you mine. Can I write you directly to your gmail ?
That will be great, thanks

Comment 9

[Yehuda]

Did some more research. Looks like the site is sending the wrong response headers after a successful login request. The response header includes a 'location' field, but has return code 200 instead of 302. Could be that Firefox 4 follows the location in this case, while Firefox 5 ignores this field, and remains in the login screen

Comment 10

[reuven]

According to Yehuda's findings this looks like a firefox bug and not Tech evangelism. This sites are used by hundreds of academy lecturers - could the developers take care of it?

Comment 11

[Tomer Cohen :tomer]

(In reply to comment #10)
> This sites are used by hundreds of academy lecturers
The same issue seems to reproduce on the students login page as well, which means that not only hundreds of academy lecturers are affected by this bug, but thousands of students as well. 

Still, we have to determine if it is actually a Firefox issue. Can someone please try to locate the exact regression range?

Comment 12

[reuven]

According to what a lecturer told me the problem started at version 4.1 .
To Mozilla developers, please take care of this bug - users run away from FF.

Comment 13

[Tomer Cohen :tomer]

(In reply to comment #12)
> According to what a lecturer told me the problem started at version 4.1 .
> To Mozilla developers, please take care of this bug - users run away from FF.

If it is Firefox fault, we could locate the exact regression range. I guess half a year would be more than enough.

The following utility will download nightlies and let you check if the problem persist. Using it we could narrow down the range to the day it happened, and this will help the developers to point on the change that caused it to happen. 

http://harthur.github.com/mozregression/

It should not take too much from your time. Thanks for your help. ☺

Comment 14

[reuven]

> The following utility will download nightlies and let you check if the
> problem persist. Using it we could narrow down the range to the day it
> happened, and this will help the developers to point on the change that
> caused it to happen. 
> 
> http://harthur.github.com/mozregression/

Actually I thought about trying to locate the regression range, although I never did this before.

But alternatively, the developers could use the information Yehuda supplied:

"The response header includes a 'location' field, but has return code 200 instead of 302. Could be that Firefox 4 follows the location in this case, while Firefox 5 ignores this field, and remains in the login screen"

to understand why FF5 remains in the login screen.

Comment 15

[Tomer Cohen :tomer]

(In reply to comment #14)
> But alternatively, the developers could use the information Yehuda supplied:
You right, but we have yet to find out why the behavior of Firefox changed recently.

Still, this could be an issue with the browser itself. I do remember that back on Firefox 1.5.0 release we had a regression with ynet.co.il encoding that caused while fixing another bug in Firefox, and it got fixed by 1.5.0.1 release.

Comment 16

[matanya]

I have checked this using mozregerssion, the result is that the change was done at the 12.4.2011 at this pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=09b605eb3e0d&tochange=a174b86200d6

hope it helps.

Comment 17

[Tomer Cohen :tomer]

It could be caused by bug 583514 - All HTML Elements should have click() and accesskey.

Comment 18

[Tomer Cohen :tomer]

I think that a fix was released either by the application manufacturer or by Mozilla (I'm using Firefox Aurora). Can you please check if you are able to login now?

Comment 19

[reuven]

(In reply to comment #18)
> I think that a fix was released either by the application manufacturer or by
> Mozilla (I'm using Firefox Aurora). Can you please check if you are able to
> login now?

I downloaded Firefox Aurora just to test and it works with Rasahim Michlol 3 sites.

Comment 20

[reuven]

If the developers fixed the bug, then please say from which version it is solved and close the bug. If not what is the status ?

Comment 21

[Tomer Cohen :tomer]

(In reply to comment #20)
> If the developers fixed the bug, then please say from which version it is
> solved and close the bug. If not what is the status ?

I have no idea, and doesn't got any reply from them, but I think that something is changed. At the beginning the submit button has no visual feedback, and now I think that is actually do something. Do you know if sce.ac.il did an update at their side?

Comment 22

[reuven]

I use 2 accounts, one at www.sce.ac.il and one at www.shenkar.ac.il . Both behave the same, both work with FF4 and Aurora, and both don't work with FF5. I am sure they did not change anything.

When you say "and NOW I think .." what do you mean by NOW ? For me NOW means FF5.

Comment 23

[Tomer Cohen :tomer]

I am using Aurora (Fx7) which I think it works well there. I don't believe it got fixed on these versions, but I'll have to check.

Comment 24

[reuven]

The new update to FF6 solved the problem.

Comment 25

[Karl Dubost💡 :karlcow]

according to previous comment, FIXED.