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.

Changed component field from Necko (was probably unfortunate pick) to Browser- General, hoping that it will get noticed finally.

I just fixed this. This should work now. pls. verify.

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.

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

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.

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.

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.

I see a parser problem here. The text: activity;src=327953;type=... is scrawled across the page just below the heading.

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.

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.

The image renders in 4.x (and I think this HTML4.0 rule is silly). I did not scroll or resize during the load.

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.

Updating QA Contact

assigning this bug to me per Warrens request

Fixed by Andreas' changes that I just checked in.

reopened because of backout

This will not make it into M13

Clearing FIXED resolution due to reopen.

Putting on PDT+ radar for beta1.

This is fixed now

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.

The changes I did to fix this were totally XP so this must be something entirely different.

I just tried it with the nightly build 20000020919 on WIN95 and it works fine. janc could you please try again?

I just tried 02/10/00 build on NT 4, and it looks fine to me.

Okay, thanks, I will close this one again ... must have been the moon phase ...

Seems to be fixt! Marking Verified