There are numerous issues to evangelize. Those issues can only be seen by owners of Bank HaPoalim accounts who have signed up to enable Internet access to their bank account, so the range of people who can participate in QA is limited. The issues (after logging in): ============================== 1. The main frame is rendered correctly (ISO-8859-8 Visual), although has an incorrect META tag specification: <meta CONTENT="text/html" ; charset="iso-8859-8" HTTP-EQUIV="Content-Type"></meta> instead of: <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-8"> 2. In "Pirut yetrot be-pikdonot shikliim", the "Hatzeg" link doesn't work. It seems to use obsolete document.layers API. 3. The menu frames have no charset specifications. 4. The menu frames seem to be delivered in UTF-8, but the Hebrew is text is laid out visually. This is invalid (Unicode is always Logical). For some reason, setting "View > Character Coding > Hebrew Visual (ISO-8859-8)" seems to "fix" the Hebrew direction (until the next time we enter the site). Evangelizing ground =================== The bank is aware of Netscape and Mozilla but refuses to support clients who mention the word "Linux" (since Linux is not a supported OS; they hardly found MacOS worthy of support). The site claims to support Netscape 6.2 (and Mozilla, according to tech suppport person), but apparently it doesn't. Also, Netscape support isn't on the top of their priorities, as they claim 95% of the users use Windows / IE 5. Status ====== The technical support department is not helpful, as their assumption is that something is wrong on your side. As of now, it is impossible to contact the technical department directly, so I'm trying to pass them a mail through a customer support person.
Mac users have the same problems as well. We have already a few bugs open about that bank. Anyone have a direct contact there?
Accepting- I think it will be a good idea to ue this bug as a tracking bug.
Points 3 and 4 are invalid as evangelism issues. Both are a result of a bug in Mozilla (see bug 165609). I will look for a workaround for the site. Anyway, a refresh of the page (click in the URL bar and press Enter, or click Reload) makes the problem go away.
Ilya, you now have permissions to confirm and resolve bugzilla bugs.
Created attachment 109391 [details] Site after selecting "Hebrew Visual" from View -> Character Coding
As of version 1.2, the Bank HaPoalim site doesn't display correctly even after selecting "Hebrew Visual" from View -> Character Coding. In all the versions up to 1.2b (including that version), selecting "Hebrew Visual" would temporarily "fix" the problem as previously described. However, from version 1.2 and later even that no longer works (as can be seen in the screenshots provided). I'm not really into HTML so I can't say exactly what's going on, only that it used to work and now it doesn't. I'm currently using version 1.3a (Build ID 2002121216) on Mac OS X 10.2.2
Another problem: When using the Password restoration page, the fields won't accept Hebrew text unless your Default Character Coding is set to ISO-8859-1 (yes, 1 and not 8). If it's set to anything else (e.g. ISO-8859-8, Windows-1255), the Hebrew text would turn into question marks. Setting the "Default Character Coding" is a common task for those who wish to correctly view pages which lack charset specification (assuming most pages I visit are Hebrew, I'd want to set the default to Windows-1255 instead of ISO-8859-1). The problem lies in BankHapoalim's treatment of the Accept-Charset header which is sent along with the submitted form, containing the user's "preferred" charset (ie. the Default Character Coding). The site is not supposed to do any processing on it when resolving the form values (which are, BTW, submitted correctly: I checked with livehttpheaders) -- but Bank Hapoalim's site does. It should be noted that BankHapoalim's support people are quite arrogant and unfriendly towards their customers ("But it doesn't matter. We don't support Linux. The bank will make its decision on what platforms to support based on financial considerations."). However, they do claim to support MacOS and Windows and since this problem appears on all platforms, they ought to fix it. It'd be nice if anyone else would care to bug them about it.
tech evang june 2003 reorg
the site serves visual hebrew to IE too.
With bug 165609 solved, we should have no more "reload to reverse menus" weirdness. However, now the menus would always be reversed, since now we behave exactly like IE (which is The Right Thing to do), while BankHaPoalim JS reverses menu texts before writing them *only* for IE. So this turns into an evangelism issue. Also, a new bug 246700 for an existing issue: the side frames being displayed in "Gibberish" characters sometimes. It's due to a Mozilla bug as well. The cause is known so I expect it to be swiftly resolved. Back to evangelising, who of you is whilling to speak to the bank as an "Israeli representative of Mozilla"? I think that, coming as an organization seeking for cooperation, there's a much bigger chance for this to work.
Now that bug 246700 is fixed, Bank HaPoalim's menus would *ALWAYS* display reversed on Mozilla, unless Bank HaPoalim fixes their site. To fix it, they'll need to edit this JS: https://www.bankpoalim.co.il/new_images/SCRIPTS/nb_MainFrameSetMenu.js?M=Mver121 and replace all 'if(browserName.indexOf("Microsoft") == -1)' checks, which choose whether to print Visual Hebrew or Logical Hebrew, with a check for Netscape 4 only: (Mozilla behaves more like Internet Explorer does) if ((browserName.indexOf("Netscape") != -1) && (browserVer < 5)) // use visual text else // use logical text Again, who will take the evangelising communications?
From a conversation with BankHapoalim's support today (both the initial person and the supervisor), they refuse to support Mozilla (even on Macintosh) except for what they define as "trivial problems". Modifying their site is, of course, not a trivial request. The supervisor told me he'll forward the request in his monthly "improvement proposals" (הצעות יעול) report. If that's any consolation, when I said "Mozilla", they could say they don't support Mozilla nor Netscape nor Firefox, so this means I'm not alone with the complaints.
Conforming summary to TFM item 10 at http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new
current status: seamonkey 1.0.6 (Gecko/20061030): uses visual hebrew, generally looks ok. firefox 18.104.22.168 (Gecko/20061025): same as above firefox 22.214.171.124pre (Gecko/20061127): text in top and right menues is displayed in reversed order. uses western (iso-8859-1) encoding. reload doesn't change anything. trying to change the encoding manually results in html code displayed where the top and right menues were. the only way i found to fix this is to reload the page. the main frame is displyed correctly. i think we have a serious issue here, considering the market share of this bank. anyone knows what happened between 1.5 and 2.0 in firefox? for reference, see attachment 199620 [details] from bug 312363, which includes a log of a session in the account.
Tsahi, after bug 165609 was solved (before 1.5), I thought 1.5 would bring an era when menus would always be reversed and then maybe the bank would fix them once and for all (they simply run an unnecessary 'reverse' function when the user-agent matched "navigator"). However, in 1.5 it was still possible to work around the reversed menu by reloading the page -- I don't know why, since I thought bug 165609 took care of this inconsistency. In any case, now the inconsistency is done and we work like a sane browser. Now, it's just the site specifically mistreating "navigator".
Ilya or Tsahi, what's the latest on this bug? Is it still a problem with Firefox 2? With Firefox 3? With Minefield (Firefox trunk nightly)? With Camino?
the bank recently updated their site. if you enter an incorrect password, you are redirected to this page: https://login.bankhapoalim.co.il/cgi-bin/poalwwwc which has this thing at it's <head> section: <Y><META CONTENT="text/html" HTTP-EQUIV="Content-Type" charset="windows-1255"></META></Y> that's a new breed of html, i guess. one thing that sometimes confuses html rookies is that the charset is the value of the content property, like so: <meta http-equiv="Content-Type" content="text/html; charset=windows-1255"> the result is that if your default encoding is not windows-1255, you will see gibberish. i'll try to login tomorrow and see how it works.
(In reply to comment #18) > the bank recently updated their site. if you enter an incorrect password, you > are redirected to this page: https://login.bankhapoalim.co.il/cgi-bin/poalwwwc [snip] > the result is that if your default encoding is not windows-1255, you will see > gibberish. Well, all Hebrew lettering looks like "gibberish" to me since I don't speak or read Hebrew ;) but I get what looks very much like a proper page layout there with UTF-8 or "autodetect" set as my default text encoding in Camino trunk and in Firefox 2 with "Universal" auto-detect set. I suspect, though I don't know for sure, that the lack of a DOCTYPE is forcing us into quirks mode, which is probably helping out with the charset issues. Other than the encoding thing -- which definitely sounds like a new bug, because this bug has been primarily focused on the bad browser-sniffing, at least as far as I can tell -- does the site work OK? What browser did you do your testing with?
using seamonkey 1.1.7, the account area looks ok, except for a few minor hickups, e.g. in the withdrawal account ("over vashav") area, there's a thing called Produce a GOLD Number, which i don't know what it is, but in english its NABI in the navigation sidebar, and IBAN in the section title. the biggest problem i found, both in SM and Firefox 126.96.36.199, is the bank messages area (doal vecelular > doar nichnas). here, the first part of the title is reversed: תורגדהו עדימ > דואר נכנס instead of מידע והגדרות > דואר נכנס, and the message list is indented to 2/3rds of the screen, so you have to scroll left to see it properly.
Those problems don't seem major enough to keep this bug open, so I'm going to resolve this FIXED. An e-mail to the bank might be helpful in convincing them to fix those last remaining issues.