bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

a part of the URL above doesn't get rendered

VERIFIED FIXED in mozilla0.9



18 years ago
17 years ago


(Reporter: Jungshik Shin, Assigned: Roy Yokoyama)



Firefox Tracking Flags

(Not tracked)




(2 attachments)



18 years ago
In recent builds (20001214xx or 20001215xx),
a part of the URL above does not get rendered.
M18, Netscape 6, Netscape 4.7x,
MS IE 5.5 and Lynx 2.8.3dev8 have no problem
with the URL above. The easiest way to confirm
this bug is view the URL above with M18 and
a recent build and compare the results side
by side.
The page at the URL above uses some dubious
(possibly standard-violating) HTML elements
and URL references, but I guess Mozilla should
get around them as do other browsers mentioned.
Looks identical in mozilla linux build 2000-12-19-08 and NS 4.7.  Probably a
duplicate of bug 62782

Comment 2

18 years ago
Reporter please try with a latest nightly, as there was in the builds you tested 
a bad html parser bug that has been fixed now.

Comment 3

18 years ago
I've just tried the newest build (2000122004) for MS-Windows
9x/NT/2000 and found that the problem remains as it was
with 2000-12-14(Windows)/2000-12-15(Linux) builds.
I'm gonna attach two screen shots of the page, one
with NS 6 and the other with 2000-12-20-04 build for MS-Windows.


Comment 4

18 years ago
Created attachment 21103 [details]
Netsape 6 rendering of the page in question

Comment 5

18 years ago
Created attachment 21104 [details]
mozilla 2000-12-20-04 build (MS-Windows) rendering of the page in question

Comment 6

18 years ago
over to Layout
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen

Comment 7

17 years ago
I don't have a korean OS to verify this issue. Reporter, is this still occuring 
in the latest build ?
Assignee: clayton → karnaze

Comment 8

17 years ago
Erik, can you take a look.
Assignee: karnaze → erik

Comment 9

17 years ago
 Jungshik Shin- Is this still a problem. This looks like a dup of 67520  
Change the component to International . reassign to yokoyama.
Assignee: erik → yokoyama
Component: Layout → Internationalization
Target Milestone: --- → mozilla0.9


17 years ago

Comment 10

17 years ago
  It appears to have been fixed by the patch for bug 67520 (which
is likely to be a dup of this bug).

  I can't be sure without more extensive testing which I can't do at
the moment because somehow all of several recent builds (including m0.8.1)
I've tried doesn't start at all under Windows ME box of mine saying
something about 'xpcom.dll' (it's NOT a JRE problem mentioned in the
release note.  It doesn't start even with files related with Java plugins
removed following the instruction given in the release note. Moreover,
I'm not using CJK version of MS-WIndows ME but English version of
MS-Windows ME with Korean/Chinese/Japanese fonts).  Under Linux, it
starts, but it takes very long(~ a few minutes) to load the page of
which URL I gave in my original report (and other pages at the site :
<http://www.hani.co.kr>. I'll try other Korean pages and see if the
problem is still there.

   BTW, "Korean OS" is  NOT a requirement for testing this (Mozilla
is much better than requiring Korean OS to view Korean web pages !).
It can be tested under any language version of MS-Windows 9x/NT/2000,
MacOS, Linux/Unix/X11 provided that Korean fonts are installed.

   Jungshik Shin

Comment 11

17 years ago
It's fixed as far as I can tell. 
By removing old profiles, I was able to 
run Mozilla in Windows ME. I think this could
be declared as fixed. 

Comment 12

17 years ago
petersen: Can you verify if this is fixed?
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 13

17 years ago
Marking verified in the May 22nd build.
You need to log in before you can comment on or make changes to this bug.