As you do I checked my page using the developer release of the NG render. Apart from crashing (not that surprising for such an early release) the counter I use on my page, which runs of a cgi bin, comes up as zero hits. Needless to say on IE and Netscape the counter says how many visits the page has go. This is fairly trivial but I thought worth a look. Here's the image tag used, see the url to see it in action. <img src="/cgi-bin/webcount?length=5&type=abacus" hspace=1 vspace=1 border=1 alt="page visits"> Cheers Stewart Dean

This appears to be a netlib bug. Can you verify?

Stewart, could you see if the form post is going ok. The way I look at it, with 4.5 netscape I get an image with some of the - filed in with a black square (an abacus). With nglayout, I see an image but with none of the - filled. The point being that an image is being displayed for the IMG tag. And I presume the image is being generated as a result of the form post. So I am wondering what is different that you generate a different image. Can you check the form post data and make sure that you get the same request with nglayout and 4.5 netscape browser. Rick, there are a few layout problems like - some of the text that needs to be centered isn't - The white main text background isnt' aligned properly Did you notice these and have a separate bug for this ?

Sorry - not really sure how I can test the form post data the server in quesiton I have no access to the cgi The image is being generated via server side script and, as seen in 4.5 fills in the blocks as the page is visited. The 'abacus' works in IE and Netscape 4.5 (although I realise this is no garantee what it is doing is legal). The cgi program in question is called webcount and is supplied by my service providor, direct connection. Documentation on how to use this is at: http://www.dircon.net/support/counter.html It uses the ? and & characters to seperate the information - I was presuming that somehow these were not getting out of gecko. The other small layout glitches may be down to non HTML 4 coding but I have noticed in the latest binary images sometimes don't load fully in. For example on the same page, second time I looked at it, the background only loaded 2/3rds of the way in - leaving black strips in the background (a non related bug). Hope this is of some help

Thanks stewart, that definitely clears some path for us. Regarding the image not loading fully the second time, that was a cache issue and gagan@netscape.com is dealing with it. For this one, I am test my theory out with other servers. Thanks for your info and interest in our browser.

Setting all current Open/Normal to M4.

pam any clues ?

Just to speed things up, I'm putting the cgi URL in the url field. Note that the original URl was http://www.webslave.dircon.co.uk/alife the cgi: http://www.webslave.dircon.co.uk/cgi-bin/webcount?length=5&type=abacus or http://www.webslave.dircon.co.uk/cgi-bin/webcount?length=5 if you would rather look at numbers instead of an abacus. Still studying the problem. No theories yet. It might be worth noting that I'm getting reports that images are taking a very long time to display. Since nothing has been checked in that affects the decoding of the image data, the delay might be affected by layout, rendering or netlib. -pn

I'm testing with the following URL so I can see digits instead of dashes and squares: http://www.webslave.dircon.co.uk/cgi-bin/webcount?length=5 I can see the counter image everytime with the Jan 28 build I have for viewer. The counter never counts(always 00000)but that is a different issue. -pnunn

I am repulling/rebuilding with the tree tip. (also probably losing my stable build. It may take awhile to get a testable build.)

The most current build does not exhibit a problem on viewer, but the huge delay times for loading does show up on apprunner. This indicates the problem is related to either layout or netlib problems. Reassigning to gagan.

investigating...

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

Marking till Necko lands...

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Pl. verify with Necko

this is fine w/necko