Hebrew site displayed with question marks

RESOLVED FIXED

Status

P3
normal
RESOLVED FIXED
18 years ago
3 years ago

People

(Reporter: dvir, Assigned: momoi)

Tracking

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Assignee)

Comment 2

18 years ago
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
(Reporter)

Comment 3

18 years ago
Created attachment 36340 [details]
The page under IE 5.5
(Reporter)

Comment 4

18 years ago
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 :-(
(Assignee)

Comment 5

18 years ago
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.
(Assignee)

Comment 6

18 years ago
Adding Gilad to the CC line.
(Assignee)

Comment 7

17 years ago
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
(Assignee)

Updated

17 years ago
Component: BiDi Hebrew & Arabic → Evangelism
(Assignee)

Comment 8

17 years ago
Accepting ... and setting the priority to P3.
Status: NEW → ASSIGNED
Priority: -- → P3
(Assignee)

Updated

17 years ago
Component: Evangelism → Asian
Product: Browser → Tech Evangelism
Version: other → unspecified
(Assignee)

Updated

17 years ago
Component: Asian → Middle Eastern

Comment 9

17 years ago
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).

Updated

17 years ago
Blocks: 115714

Comment 11

17 years ago
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"

Comment 13

17 years ago
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. 

Comment 14

17 years ago
still there with trunk buil 2002020103 on mac 9.2.2 . Would it be possible to
increse our tolerance for code like this?

Comment 15

17 years ago
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.
(Assignee)

Comment 16

17 years ago
> 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)
(Assignee)

Comment 18

17 years ago
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.


 

Comment 19

16 years ago
*** Bug 134087 has been marked as a duplicate of this bug. ***

Updated

16 years ago
OS: Windows 98 → All
Hardware: PC → All

Updated

16 years ago
Blocks: 163659

Comment 20

16 years ago
> 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.

Comment 21

15 years ago
tech evang june 2003 reorg
Component: Middle Eastern → Hebrew

Comment 22

15 years ago
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?

Comment 23

15 years ago
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

Comment 24

15 years ago
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. 

Updated

15 years ago
QA Contact: ruixu → momoi
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.