When loading the URL all the text is displayed as question marks. It might be related somehow to the fact it's a secured page. In order to load it you'll have to disable "TLS" in the SSL preferences.
ie5.5 reports page is iso-visual
We support iso-8859-8 (visual). In fact that is the default order for 8859-8. I am not able to view this page with IE5.5, either. I would like to know if anyone has succeeded in viewing this page with any browser. It is possible that characters/bytes on the page are incorrect to begin with. I'm going to confirm that the problem does exist but am not sure if this is not the fault of the page itself.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I attached a screen shot of this page under IE 5.5 . I also used to have it working under Netscape 4.7, but I can't prove it :-(
Thanks, D. I still can't display this page with IE 5.5 or Mozilla 5/27/2001 build. But I was able to display it with Communicator 4.61- IBM bidi special version.
Adding Gilad to the CC line.
Update: 1. This site runs a server which has a TLS rollback problem. The server is: Stronghold/2.1 Apache/1.2.4 UKWeb/2045 As mentioned above, the workaround is to turn off the TLS option in the SSL protocol preference. 2. However, once you get past this TLS problem, there is another problem. This site uses incorrect syntax for meta-charset tag. This is what the page includes: <meta HTTP-EQUIV="Content-Type" CONTENT="text/html" ; charset="iso-8859-8"> The CONTENT description must include all the way till the end of the "iso-8859-8". When you correct this line to: <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-8"> eliminating 2 instances of ", Mozilla is able to display the page correctly. By the way, you should be able to override the incorrect reading of charset by engaging the View | Character Coding menu. This is an evangelism bug and so will re-assing this to myself. CC'ing ftang. Frank, it might be worth our our while to build in some error-tolerance for something like this in parsing the meta charset line.
Assignee: mkaply → momoi
QA Contact: momoi → jonrubin
Accepting ... and setting the priority to P3.
Status: NEW → ASSIGNED
Priority: -- → P3
Component: Evangelism → Asian
Product: Browser → Tech Evangelism
Version: other → unspecified
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
I can view the page correctly in 0.9.6. It appears to me that tolerance for this incorrect meta-charset syntax was introduced by jbetak's patch in bug 91696. QA, can you confirm and (I hope) resolve? cc-ing shanjian as reviewer of the patch (since jbetak is no londer here).
Tested with Mozilla ID 20022012103 on Mac OS 9.2 with my defoult chaset set as windows-1255. The page at first affeared with reversed text, but changing the ecoding manually fixed it. Strange, since the page does has the following meta tag: <meta HTTP-EQUIV="Content-Type" CONTENT="text/html" ; charset="iso- 8859-8"></meta> Not sure why mozilla did not idetify it correctly? at any case, no question marks are displayed at any state.
See comment 7: the correct syntax of the meta-charset tag is ...CONTENT="text/html; charset=iso-8859-8" not ...CONTENT="text/html" ; charset="iso-8859-8"
Recent trunk build displayed the page fine. Mozilla could tolerate such ill-formed charset specification. Please verify this and close this bug. If problem still exist in current build, I will see if our tolerance need to be improved or not.
still there with trunk buil 2002020103 on mac 9.2.2 . Would it be possible to increse our tolerance for code like this?
I'm not sure the diagnosis of this problem is accurate. The page I'm using is http://www.maariv.co.il/ and it has a correctly formatted META tag. I'm seeing the question marks on the Macintosh version of 0.9.7. The page displays correctly on the Win32 build.
> I'm not sure the diagnosis of this problem is accurate. It used to be correct. Something else migh be going on now at this site. We are not able to correct teh display any more even with changing teh Character Coding menu. It seems incorrect data are sent to Mozillal. It is displayed OK under IE5.5. We should re-analyze problems on this site.
spongman: if you see Hebrew correctly on Windows and question marks in Mac, you are seeing bug 86253, which is fixed in recent builds (including the 0.9.8 branch)
I made some progress on this problem with the help of smontagu. This site seem to send different sets of data depending on what user-agent is requesting the page. For exapmle, the page displays OK on recent Netscape Mac trunk builds -- the server sends a page encoded in Windows-1255 correctly. On the other hand, the server sends corrupted data with the charset tag of ISO-8859-8 to a recent Windows Netscape trunk build. It sends yet another page to Windows Netscape 6.2.1 which is displayable correctly as ISO-8859-8. Presumably, the same is true for Mozilla milestone builds such as 0.9.8. The picture is quite confusing because the site sends different data with different charsets depending on Mozilla/Netscape builds and versions. So it turns out that on a recent Win 32 trunk build, this site sends unreadable ISO-8859-8 data. No, the Hebrew display is not broken on these recent Windows builds. It is OK on other ISO Vidual sites. Thus, my tenative conclusion is that if they are going to discriminate this way, at least they should send readable/correct Hebrew data to all clients/browsers. I guess that would be my point in the next message I send them.
*** Bug 134087 has been marked as a duplicate of this bug. ***
> So it turns out that on a recent Win 32 trunk build, > this site sends unreadable ISO-8859-8 data. The site is perfectly readable with the latest Win32 nightly. UA string: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030109 Prog.
tech evang june 2003 reorg
Component: Middle Eastern → Hebrew
There is no encoding problems on the site. Probably they fixed it, while they changed the design with the current one. should we close this bug? Can a subscriber of Bank Hapoalim confirm that the site working fine under Gecko, or need a new bug?
According to the linux-il list, the site is now fine. people with poalim accounts- pleae confirm
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Confirming. This problem is gone, replaced by the problem of "reversed Hebrew until you perform Reload", which is fully documented (and completely disregarded by the developers) as bug 165609.
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.