Closed Bug 31424 Opened 25 years ago Closed 25 years ago

content of html file missing in the middle of file

Categories

(Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 38244

People

(Reporter: leealwc, Assigned: neeti)

References

()

Details

Attachments

(7 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.12-20 i586; en-US; m14)
BuildID:    2000030913

When I navigate http://www.mingpao.com/ (and some other sites, too), quite often
the page displayed is corrupted. The beginning and end of the file is there when
I read the source in "View Source", but some parts in the middle is missing.

Reproducible: Sometimes
Steps to Reproduce: Goto URL above.
Attached file Expected Result (deleted) —
Attached file Actual Result (deleted) —
This page renders teh same for me in mozilla as it does in IE4 (performance is
horrible but it looks the same)  Are you still seeing this in current builds?
yes... it still occurs in build 2000032405.
-> Parser (maybe?)
Assignee: cbegle → rickg
Component: Browser-General → Parser
QA Contact: asadotzler → janc
leeal@earthling.net - still seeing this? WORKSFORME in 20000511...

Gerv
I can't reproduce this on the page:
  http://www.mingpao.com/newspaper/20000311/_ged1h.htm

but it still occurs on some other pages at the same site.
  http://www.mingpaonews.com/20000512/_taa1h.htm
  http://www.mingpaonews.com/20000512/_taa2.htm
leeal@earthling.net - these are pages with frames. The default View Source will 
naturally show a very small page. 

The first URL display fine for me in 20000514. leeal@earthling.net - what build 
of Mozilla are you using (bottom right corner of browser)?

The second one looks different, but the source is the same.

Gerv
I was using build 20000511 the last time.
About the links I posted last time, I was actually referring 
to the frame on the right hand side. So the correct link should
be:
- http://www.mingpaonews.com/20000512/taa1hr.htm
- http://www.mingpaonews.com/20000512/taa2r.htm
(note that these are not the only pages having problem.)

The problem does not always appear. Sometimes it displays correctly
the first time it's loaded, but might have problem after RELOAD. For
the times that the output is corrupted, it might not look the same
every time, either.
 
I just retested it with Build 2000051520. This time the first link
have problem and the second one looks fine.
If you save a good version of it to your local disk, do you still get this 
behaviour when loading the page from there?

Do you only ever see this problem in Mozilla?

Gerv
Second one first: yes, only seen this problem in mozilla.

First one: I tried it with http://www.mingpaonews.com/20000512/taa1hr.htm
It displays perfectly in mozilla when it's saved (from Netscape) to 
local disk first.
So it's definitely not a rendering problem then; either something to do with the 
networking code, or a problem with the original website. I don't really know 
what to do now... Move to Networking?

Gerv
Gagan: I'm not seeing this problem (on NT). Can you reproduce it? I expect you 
have better tools to test the networking aspects that I do.
Assignee: rickg → gagan
Component: Parser → Networking
WORKSFORME on 2000060508 Linux.

We need to resolve this ASAP. There's an excessive amount of Linux unconfirmed
bugs. Reporter (leeal@earthling.net), please try to reproduce on a new build
from ftp.mozilla.org. If there aren't any additions to this within the week, I'm
going to resolve as WORKSFORME.
Attached image June 6: Build 2000060520 Try 1 (deleted) —
Attached image June 6: Build 2000060520 Try 2 (deleted) —
Attached image June 6: Build 2000060520 Try 3 (deleted) —
eliot@landrum.cx,

I retested it on build 2000060520 and it still occurs.
I tested it on the page http://www.mingpaonews.com/20000606/cdb1hr.htm for three
times. All generate different output. I have attached the screenshot of them and
a screenshot of the correct output by Netscape 4.73.
leeal@earthling.net - you'd be better off doing a File | Save As... and saving 
the HTML file that the browser is trying to render. Then, we can see if it's the 
Networking Library hiding some of the content, or the parser missing some out, 
or what. Screenshots confirm the problem, but they don't take us any closer to 
solving it.

Gerv
leeal@earthling.net - I have run this document through the w3c's tidy program,
reinserted the proper text, and made it completely HTML 4.0 transitional
conformant. This included adding the proper DOCTYPE and a lang attribute to the
root <html> tags. Please check this new attachement and see if you can still
duplicate your problems. I believe the biggest problem with the original
document was the lack of quotes around attribute values. That's fine for just
some numbers like 0 or 1, but when you start getting to path names
(../blah/img.jpg) or hex values (#0000000), it starts getting messy. tidy fixed
all that.

Anyway, let's see how this does. Don't worry about screenshots this time.
Gervase: the file mozilla saves to disk looks fine. it also displays that local
file fine. then i use the 'back' button to go back (to the original url). at
first it is fine (load from cache?), when I reload, problem occurs again.

eliot@landrum.cx: problem still occurs.
sounds like a bug to me.  Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
->neeti
Assignee: gagan → neeti
Status: NEW → ASSIGNED

*** This bug has been marked as a duplicate of 38244 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
This bug still occurs in build 2000080720. One page that it occurs
quite frequently (on my computer :) ) is:
	http://www.mingpaonews.com/20000512/taa2r.htm

Seems that this problem occurs more frequently with pages that contains
chinese characters.
QA Contact: janc → tever
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: