Closed
Bug 16575
Opened 25 years ago
Closed 25 years ago
Fails to download some files on a page
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: r_rom, Assigned: andreas.otte)
References
()
Details
(Whiteboard: [PDT+])
Attachments
(1 file)
75.14 KB,
image/gif
|
Details |
Build: 10-15-99
STEPS TO REPRODUCE:
1. If the page didn't change by the time you read this, go to
http://www.newspage.com/.
RESULTS:
Mozilla fails to download (or at least to display it) several images:
a) two of them are ads (I couldn't figure figure out their URL's by looking at
the source). One ad was close to the top and the other one was close to the
bottom of the page.
NN 4.7 did NOT have problems with these two.
b) URL of one image that it failed to get was
src="\newsdesk\home\images\home_image.jpg?1015175848?". NN 4.7 failed to
download it too. However, when I changed '\' to '/' and typed it on the URL
bar, NN 4.7 was able to download it. Looks like it didn't like the backslash.
IE 5 had no problems.
Updated•25 years ago
|
Assignee: don → gagan
Component: Browser-General → Necko
Changed component field from Necko (was probably unfortunate pick) to Browser-
General, hoping that it will get noticed finally.
Now the browser crashes (build 10-27-99). See attachment and note what is
displayed instead of the ad banner near top of the page.
During downloading of the page (www.newspage.com), partially rendered page is
cleared and the rendering process seems to restart.
Assignee | ||
Comment 6•25 years ago
|
||
It renders fine with todays linux build, but crashes after some time. This ist a
stacktrace:
Program received signal SIGSEGV, Segmentation fault.
0x4002ac4c in ImageConsumer::OnStopRequest (this=0x8989340,
channel=0x409fc1a0, aContext=0x4002a330, status=144511736, aMsg=0xbfffeea8)
at nsImageNetContextAsync.cpp:360
360 ilINetReader *reader = mURL->GetReader();
(gdb) backtrace
#0 0x4002ac4c in ImageConsumer::OnStopRequest (this=0x8989340,
channel=0x409fc1a0, aContext=0x4002a330, status=144511736, aMsg=0xbfffeea8)
at nsImageNetContextAsync.cpp:360
#1 0x409e4fbc in nsChannelListener::OnStopRequest (this=0x89894b8,
aChannel=0x409fc1a0, aContext=0x4002a330, aStatus=144511736,
aMsg=0xbfffeea8) at nsDocLoader.cpp:1377
#2 0x409e4fbc in nsChannelListener::OnStopRequest (this=0x8ab8fd0,
aChannel=0x409fc1a0, aContext=0x4002a330, aStatus=144511736,
aMsg=0xbfffeea8) at nsDocLoader.cpp:1377
#3 0x409e4fbc in nsChannelListener::OnStopRequest (this=0x89d12a0,
aChannel=0x409fc1a0, aContext=0x4002a330, aStatus=144511736,
aMsg=0xbfffeea8) at nsDocLoader.cpp:1377
#4 0x4002a3a0 in ImageConsumer::OnStartRequest (this=0x89d12f8,
channel=0x8904ae8, aContext=0x0) at nsImageNetContextAsync.cpp:168
#5 0x409e4d9c in nsChannelListener::OnStartRequest (this=0x89d1508,
aChannel=0x8904ae8, aContext=0x0) at nsDocLoader.cpp:1347
#6 0x409e4d9c in nsChannelListener::OnStartRequest (this=0x885b580,
aChannel=0x8904ae8, aContext=0x0) at nsDocLoader.cpp:1347
#7 0x409e4d9c in nsChannelListener::OnStartRequest (this=0x8ab1f38,
aChannel=0x8904ae8, aContext=0x0) at nsDocLoader.cpp:1347
#8 0x4153b67c in nsHTTPResponseListener::FinishedResponseHeaders (
this=0x8905d80) at nsHTTPResponseListener.cpp:603
#9 0x4153a41c in nsHTTPResponseListener::OnDataAvailable (this=0x8905d80,
channel=0x8abab08, context=0x8904ae8, i_pStream=0x8909328,
i_SourceOffset=0, i_Length=1234) at nsHTTPResponseListener.cpp:151
#10 0x4097809a in nsOnDataAvailableEvent::HandleEvent (this=0x416043e0)
at nsAsyncStreamListener.cpp:412
#11 0x40977472 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x416004d8)
at nsAsyncStreamListener.cpp:169
#12 0x401be6eb in PL_HandleEvent (self=0x416004d8) at plevent.c:537
#13 0x401be5a9 in PL_ProcessPendingEvents (self=0x80a0b08) at plevent.c:498
#14 0x401758bd in nsEventQueueImpl::ProcessPendingEvents (this=0x80a0ae0)
at nsEventQueue.cpp:190
#15 0x40567c50 in event_processor_callback (data=0x80a0ae0, source=7,
condition=GDK_INPUT_READ) at nsAppShell.cpp:228
#16 0x4056741f in our_gdk_io_invoke (source=0x81b1088, condition=G_IO_IN,
data=0x8247108) at nsAppShell.cpp:49
#17 0x40718e2a in g_io_unix_dispatch (source_data=0x81b10a0,
current_time=0xbffff5e0, user_data=0x8247108) at giounix.c:135
#18 0x4071a663 in g_main_dispatch (current_time=0xbffff5e0) at gmain.c:656
#19 0x4071ac9b in g_main_iterate (block=1, dispatch=1) at gmain.c:874
#20 0x4071ae51 in g_main_run (loop=0x827cfc0) at gmain.c:932
#21 0x4063808b in gtk_main () at gtkmain.c:476
#22 0x405681bf in nsAppShell::Run (this=0x80a1528) at nsAppShell.cpp:395
#23 0x403dd0b5 in nsAppShellService::Run (this=0x80a0818)
at nsAppShellService.cpp:484
#24 0x804b768 in main1 (argc=1, argv=0xbffff814) at nsAppRunner.cpp:579
#25 0x804ba19 in main (argc=1, argv=0xbffff814) at nsAppRunner.cpp:669
#26 0x402ca213 in __libc_start_main (main=0x804b860 <main>, argc=1,
argv=0xbffff814, init=0x8049c90 <_init>, fini=0x804e7f0 <_fini>,
rtld_fini=0x4000ac30 <_dl_fini>, stack_end=0xbffff80c)
at ../sysdeps/generic/libc-start.c:90
Assignee | ||
Comment 7•25 years ago
|
||
It does not render so fine, in fact from compairing to 4.61, it is missing an
add. This may be the crash I am seeing.
Assignee | ||
Comment 8•25 years ago
|
||
I think the missing adds are included in the page with the LAYER tag. Do a view
source and go to the end of the page. The LAYER-tag is not supported.
Assignee | ||
Comment 9•25 years ago
|
||
No, I was wrong, this is a dup of the urlparser-bug in bug 14801. If you use the
patch attached there, the adds are loading.
Updated•25 years ago
|
Assignee: gagan → rickg
Status: REOPENED → NEW
Component: Browser-General → Parser
Target Milestone: M13
Comment 10•25 years ago
|
||
I see a parser problem here. The text:
activity;src=327953;type=...
is scrawled across the page just below the heading.
Assignee | ||
Comment 11•25 years ago
|
||
Warren, have you looked at 14801? I see two problems there, one with the parser
that is solved with the patch attached there and one other bug (I think layout)
which leakes some html strings into the layout. This does not only happen with
images, but also with links or tables. It happens sometimes if you start moving
the scrollbar or resize during the pageload. I have not seen this problem when I
waite until the page is completely loaded.
Comment 12•25 years ago
|
||
This is not a bug, as far as I can tell. The image specified is bogus, and the
layout system tries to render the URL as text in it's place (per the HTML4.0
spec, section 13.3).
Giving back to warren in case he has any residual issues.
Comment 13•25 years ago
|
||
The image renders in 4.x (and I think this HTML4.0 rule is silly). I did not
scroll or resize during the load.
Assignee | ||
Comment 14•25 years ago
|
||
Warren, what you see currently is most likely the urlparser bug in action I
described in bug 14801. It results in a bogus image URL => instead of the image
the path (or part of it) is shown. With the patch from 14801 applied I don't see
that, what I was refering to, were some other strange things happening during
layout, when stressing it with resizing/scrolling during download.
Comment 15•25 years ago
|
||
Updating QA Contact
Assignee | ||
Updated•25 years ago
|
Assignee: warren → andreas.otte
Assignee | ||
Comment 16•25 years ago
|
||
assigning this bug to me per Warrens request
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 17•25 years ago
|
||
Fixed by Andreas' changes that I just checked in.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M14
Assignee | ||
Comment 19•25 years ago
|
||
This will not make it into M13
Comment 20•25 years ago
|
||
Clearing FIXED resolution due to reopen.
Assignee | ||
Comment 22•25 years ago
|
||
This is fixed now
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 23•25 years ago
|
||
I can't get this page to load at all on today's WinNT build (2000-02-09-17-M14)
r_roman, do you still see this?
Reopening.
Looks fine on Linux.
Assignee | ||
Comment 24•25 years ago
|
||
The changes I did to fix this were totally XP so this must be something entirely
different.
Assignee | ||
Comment 25•25 years ago
|
||
I just tried it with the nightly build 20000020919 on WIN95 and it works fine.
janc could you please try again?
Reporter | ||
Comment 26•25 years ago
|
||
I just tried 02/10/00 build on NT 4, and it looks fine to me.
Assignee | ||
Comment 27•25 years ago
|
||
Okay, thanks, I will close this one again ... must have been the moon phase ...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•