418256 - Youtube multiuploader page no longer working with beta 3

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Lalit]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3

Youtube multiuploader does not work with Firefox 3 beta 3 

Go to 
1)http://youtube.com/my_videos_multiupload
2)Install youtube multiuploader if not already installed
3) Select a video file in acceptable format (wmv,avi,flv etc ) and add that video 
using "Add Videos to List"
4) On adding you will see that filename under "Filename"
5)Add something to title and description and tags
6)Click on upload all videos 
You should see an error message which was not happening earlier in beta 2 and it refuses to recognise data entered in the title inout field

Reproducible: Always

Steps to Reproduce:
1)http://youtube.com/my_videos_multiupload
2)Install youtube multiuploader if not already installed
3) Select a video file in acceptable format (wmv,avi,flv etc ) and add that video 
using "Add Videos to List"
4) On adding you will see that filename under "Filename"
5)Add something to title and description and tags
6)Click on upload all videos 
Actual Results:  
Please add a title and description for: "filename" Alert message is displayed

Expected Results:  
File has been added or similar message should appear
and a progress indicator in percentage (ie 10% should appear under Status column in youtube)

Comment 2

[Martijn Wargers (dead)]

I can confirm that the uploading doesn't work in current trunk build.

I get this error in the error console:
Error: files is null
Source File: http://youtube.com/my_videos_multiupload
Line: 1
uproxy.getFileArray() apparently doesn't work anymore (where uproxy is the special Google flash object).

Not sure if this is a problem with the Google uploader or with Firefox.

Comment 3

[Martijn Wargers (dead)]

This regressed between 2007-12-12 and 2007-12-13:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-12+04&maxdate=2007-12-13+06&cvsroot=%2Fcvsroot

Comment 4

[Martijn Wargers (dead)]

Backing out the patch from bug 405741 fixes this.
Apparently, there is some naming clash going on here.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

Ok, this is what I think is going on at the google youtube videouploader page.

They use the files array which is a global variable and they try to access that variable from inside an event handler in an input.
This doesn't work anymore in current trunk build, because now there is a files property on the input element, which is now accessed instead of the global variable.

Comment 6

[Martijn Wargers (dead)]

I guess this is kind of bad. Should Mozilla change the name back into fileList for example or should Google change their page?

Comment 7

[Boris Zbarsky [:bzbarsky]]

The closest to a spec here is bug 371432 comment 21.

Ideally, given how in-the-air all this is, we would use a name that isn't likely to collide with web pages, for now.  Say mozFileList.  Breaking youtube upload is certainly "kind of bad", no matter what.  ;)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Ian, you might be interested in this for web forms purposes...

Comment 9

[Lalit]

I had given up on this bug long ago
I thought nobody would notice this bug 
Just like some other bugs that I am facing.
Suddenly I am receiving a lot of bug change emails 
What changed to even consider my bugs ??

Comment 10

[Boris Zbarsky [:bzbarsky]]

Someone who knew what was going on triage-wise, moved it to the right place, and cced the right people got a hold of it....

We really need better incoming bug triage.  :(

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So unfortunately this is just the business of adding new features with the way that javascript works. We had a very similar problem when adding getElementsByClassName.

Sure, we could rename it to mozFileList, but if we do that we should do it out of concern that a future standardized API will clash with ours. I don't think we should or can rename in order to avoid name clashes with javascript variables out there.

Punting this one to evangelism.

What youtube needs to do here is to name their variable 'files' something else.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Right; the only question is how likely the final spec is to use this naming.

Note that the page could also use window.files in the event handler.

Comment 13

[Martijn Wargers (dead)]

How can we get Google to update their code? It seems worthwhile to do a bit of tech evangelism in this case.

Comment 14

[Carsten Book [:Tomcat]]

cc'ing kev to this bug, because of comment #13

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I suspect that it's very likely that a spec would use 'files' as name. The concern would be that they return an object incompatible with ours for the actual file.

Comment 16

[lastword]

Any development on this? With FF3 now in full public release and the popularity of YouTube, this is going to cause a lot of grief.

Comment 17

[Boris Zbarsky [:bzbarsky]]

This is a tech evangelism bug.  It needs to be fixed on the youtube end.

Comment 19

[Lalit]

Isn't this fixed yet?
Does it still occur in Firefox 3.5

Comment 21

[Karl Dubost💡 :karlcow]

The URL is now invalid.