154218 - Streaming webcam no longer working - javascript replaced image broken - regression

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect, P2)

Description

[WD]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020619
BuildID:    2002061908

Starting with the 2002061908 trunk builds, my streaming webcam is no longer
working.  It will display one frame (if that) and then go to a broken image.   
Builds before this date were fine.    Builds from this date on (through todays:
20020625) are broken.

Reproducible: Always
Steps to Reproduce:
1.Go to : http://dormcam.mine.nu:8080/main.php
(or http://www.sandiegozoo.org/special/pandas/pandacam/ )
2.Wait until the video connects
3.

Actual Results:  One frame and then it stops.   (Broken image usually)

Expected Results:  Image "streams" using Javascript.

There are no errors in the Javascript console

Comment 1

[WD]

It's just a guess, but I think this bug was caused by the fix for bug 148199

Comment 2

[Alexandru Savulov]

taking. goddamn piece of... 

Comment 3

[Alexandru Savulov]

in this thing nothing cannot be repaired anymore. change something, break 100000
other things.

reporter:

what is the javascript u use? please attach it.

Comment 4

[Alexandru Savulov]

oh and btw: thx for the found regression

Comment 5

[Alexandru Savulov]

reporter:

so far, i don't think is a real regression. your javascript is generating a
bunch of broken links. only every fourth is a valid one looks like.

maybe this is an evangelism. investigating.

Comment 6

[WD]

Attachment: Javascript for Webcam (dormcam and panda cam both use similar)

Alexandru:   Perhaps mozilla is being over-eager about deciding if a
javascript-replaced image is broken?   Is there any kind of timeout before
Mozilla decides that the image is broken?   (For example, if the video server
is slow...  which is probably the case with the dormcam link)

If that's the case, is there any way to increase such a timeout in the
Javascript itself?

Comment 7

[Alexandru Savulov]

Attachment: testcase to show the broken links

i modified the javascript to show that there are broken links.
open attachment in mozilla. move the popup so you can see the top of the page.
every time the new requested image is not sent from the server, mozilla will
ask you where to save whatever it comes there. i see how this works from the
client perspective:

- you generate as many URLs as possible and place a timeout to change the SRC
attribute of the image every time the previous image has loaded. here you rely
on the bug that if there is a broken link (no image comes from the server) the
browser will live the previous image there. well, unfortuantely that has
changed. and broken images do not fire onLoad.

Comment 8

[Alexandru Savulov]

unfortunately, i cannot tell what can be done on the server. i see that the
server works somehow like this:

- if there is a request from a client and an image is ready it will send the image
- if there is another request from the same client and there is no new image ready
  it will send nothing (to save bandwidth, that is legitimate)
  ......
- if there is another request from a client and a new image is ready it will send 
  the image

and so on.

the problem is that mozilla will stop the execution of the onLoad cycle as soon
as there is a broken image. the approach was good as long as mozilla didn't
changed it's policy in handling broken SRC changes. now is screwed.

maybe the server should sleep in a loop until a fresh image is ready when the
request arrives instead of answering with an empty response. so the
client(mozilla) will wait until the server responds and replace the image (from
what i see the images are generated pretty fast so the client timeout is long
enough to wait until a new image is generated).

with php this could be done somehow like this


while (!newImageReady) {
sleep(1000); //wait 1000 ms
newImageReady = CheckForNewImage();
}
// now send the new image

(note: this is just a guess. i don't really know what is on the server)


as long as the server answers a request with an empty answer the problem will be
there.
 
hope this helps

Comment 9

[Alexandru Savulov]

guys:

looks like some content providers are using the "feature" of not displaying the
broken icon when the new SRC value of an image is a broken link. goddamit! this
is really annoying that as soon as there is a bug everybody is exploiting it.
now i'm not sure, but if there are a lot of content providers using this kind of
trick to get images from web cams or whatever, we are again in a dilemma.
although i don't like this, we might be constrained to do something about. there
are 2 ways of solving it:

- fire the onload event even for broken images (what is somehow pathetic)
- use the broken image only in composer mode.

damn, damn, damn, damn....

what do you think guys?

Comment 10

[Kathleen :Brade]

OK, I'm not really positive about this but it seems to me that the onload event
should be fired regardless of whether the link is broken or not; shouldn't it?
(or will doing that break someone else in some other scenario)?  It sounds
broken (to me) that an onload event isn't fired for broken urls; does the dom
spec speak to this particular case?

Comment 11

[WD]

brade:

As for breaking other things I'm not sure ( ask Alexandru! ;-)
but the behavior you suggest (onload even for broken images) should keep the
webcam in this bug streaming.

I can't find any W3C reference, but there's a Netscape Javascript doc for Onload:
http://developer.netscape.com/docs/manuals/communicator/jsref/evnt13.htm

Scroll down to Example 4 at the bottom.  That's basically describing what's
going on with the webcam javascript.  From that text:  "This is because when the
src property changes, the image's onLoad event handler is triggered and the
changeAnimation function is called."      

To keep the behavior like it was before (constant streaming, no broken frames
mixed in with the good ones), I wonder if some combination of the 2 solutions
listed in comment #9 would be best?     Just a guess...

Comment 12

[Alexandru Savulov]

as soon as i get a fresh build, will investigate further.

Comment 13

[WD]

Switched webcam software, and I can no longer reproduce this problem, nor can I
find any other URL which exhibits the issue.

-> WFM