If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

NECKO: Counter not counting.

VERIFIED FIXED in M9

Status

()

Core
HTML: Parser
P2
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: stewart, Assigned: Gagan)

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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

Updated

19 years ago
Assignee: rickg → dp

Comment 1

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

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 2

19 years ago
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 ?
(Reporter)

Comment 3

19 years ago
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

Comment 4

19 years ago
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.

Comment 5

19 years ago
Setting all current Open/Normal to M4.

Updated

19 years ago
Assignee: dp → pnunn
Status: ASSIGNED → NEW

Comment 6

19 years ago
pam any clues ?

Updated

19 years ago

Comment 7

19 years ago
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

Comment 8

19 years ago
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

Updated

19 years ago
Summary: Strange characters in img src? → Counter not counting.

Comment 9

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

Updated

19 years ago
Assignee: pnunn → gagan
Status: ASSIGNED → NEW

Comment 10

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 11

19 years ago
investigating...

Comment 12

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

Updated

19 years ago
Target Milestone: M4 → M6
(Assignee)

Comment 13

19 years ago
Marking till Necko lands...
(Assignee)

Comment 14

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

Comment 15

19 years ago
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.
(Assignee)

Updated

18 years ago
Summary: Counter not counting. → NECKO: Counter not counting.
(Assignee)

Comment 16

18 years ago
Pl. verify with Necko

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 17

18 years ago
this is fine w/necko
You need to log in before you can comment on or make changes to this bug.