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




17 years ago
17 years ago


(Reporter: wd, Assigned: alexsavulov)



Windows 2000

Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
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 :
(or )
2.Wait until the video connects

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


17 years ago
Keywords: regression

Comment 1

17 years ago
It's just a guess, but I think this bug was caused by the fix for bug 148199
Summary: Streaming webcam no longer working - regression → Streaming webcam no longer working - javascript replaced image broken - regression

Comment 2

17 years ago
taking. goddamn piece of... 
Assignee: pavlov → alexsavulov

Comment 3

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


what is the javascript u use? please attach it.

Comment 4

17 years ago
oh and btw: thx for the found regression

Comment 5

17 years ago

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

17 years ago
Created attachment 89201 [details]
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

17 years ago
Created attachment 89204 [details]
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

17 years ago
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
hope this helps

Comment 9

17 years ago

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

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

17 years ago

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:

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

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


17 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.2alpha

Comment 13

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

-> WFM
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.