290154 - Save File dialog is opened twice in some cases

Status: RESOLVED INVALID

(Firefox :: File Handling, defect)

Description

[jmordax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

For some reason when you press a link which points to a zip file, the Save File
dialog is openend twice (you can select save or cancel and when finished the
dialog appears again).

In the page at http://www.geocities.com/jmordax/testcase.html there are three
links to demostrate the problem. Failing one is the first one. What is different
from the other two ones, is that it points to a different server from the HTML
page one.

After some research, the same test page in other server different from
Geocities.com it doesn't happen. So it seems to be related with Geocities.com
server. So looking for differences, I found that Geocities.com adds some
JavaScript code which could be the problem.

This problem, happens also with Mozilla 1.7.6 and InternetExplorer 6.0 without
WinXP SP2. After installing WinXP SP2 the problem dissapears. Searching the web,
I found this technote from Microsoft which I think can offer some light:
http://support.microsoft.com/kb/q238588/



Reproducible: Always

Steps to Reproduce:
1. Press on first link of the page http://www.geocities.com/jmordax/testcase.html
2. Select cancel in the Save File dialog.
3. The Save Dialog will open again.

Actual Results:  
The Save Dialog will open again.

Expected Results:  
Nothing should happen.

Comment 1

[Gabriel Chadwick]

I reproduced this bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050411 Firefox/1.0+ only once. Every other time i tryed to
reproduce it dit not work.

Comment 2

[jmordax]

Gabriel, I downloaded and performed the same test with Mozilla 1.8b: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217 and was
able to reproduce 100% times the problem.

Remember that the failing link from the test page is just the first one. Where
can I get the code you are using to reproduce the problem?

Regards,

   Chemi.

Comment 3

[jmordax]

I have downloaded last Firefox build: Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b2) Gecko/20050412 Firefox/1.0+ and I still reproducing the problem
100% times.

Regards,

   Chemi.

Comment 4

[jmordax]

Ok. I have more info. After some research, I detected that if JavaScript is
disabled, problem doesn't occurs. Using JavaScript Debugger included with
Mozilla 1.7.6 I found that the piece of code that is executed when you press a
link in a web site at Geocities.com is function cH from file
http://us.geocities.com/js_source/geovck05.js (this code is added automatically
by Geocities.com site, is not mine).

I am not really an expert on JavaScript. Can you help me to investigate if the
Save Dialog is opened twice because there is a bug in Mozilla/Firefox or because
the JavaScript function is wrong?

Also, I am not sure if in case of a bug, this is the component (File Handling)
where this bug entry should be queued.

Thanks in advance,

   Chemi. 

Comment 5

[jmordax]

Here is what is executed from the JavaScript function (I removed all the lines
not executed in my debug session). I also added the real value of each variable
when executing the code:

var d = document;
var w = window;
var h = location.hostname;

function cH(e)
{
 e = e || window.event;              // e = {Event}
 var tgt = e.target || e.srcElement; // tgt = {HTMLAnchorElement}

 var uPath = tgt.pathname;           // uPath = "/~jmordax/practicas/lector.zip"
 var uHash = tgt.hash;               // uHash = ""
 var uHref = tgt.href;               // uHref =
"http://people.javahispano.org/~jmordax/practicas/lector.zip"
 var uHostname = tgt.hostname;       // uHostName = "people.javahispano.org"
 var uTarget = tgt.target;           // uTarget = ""
 var uNodename = tgt.nodeName;       // uNodeName = "A"
 var uProt = tgt.protocol;           // uProt = "http:"
 var ytg = uTarget;                  // ytg = ""
 ytg = ytg.toLowerCase();

 top.d.location.href = uHref;
}

As I said I am not an expert in JavaScript, but I suspect that what is happening
is that with the click on the link, Mozilla/Firefox starts to load the URL and
in parallel also it executes this function (cH). When the funtion executes:
"top.d.location.href = uHref" I suspect, Mozilla/Firefow starts a new thread
loading again the URL. And that is the reason why the Save Dialog opens twice.

Any expert in JavaScript and Mozilla/Firefox can confirm this? Is this working
as designed? Or Mozilla/Firefox should wait to the execution of the funtion cH
before loading the URL (I understand that perhaps the function could want forbid
the loading of that link)?

Note: Tell me if this bug entry should be moved to other component queue.

Thanks in advance,

   Chemi.

Comment 6

[jmordax]

Information posted in Mozilla forum by Roland de Ruiter:

<<
The problem is *not* Mozilla/Firefox, but the Geocities script.

I've been debugging the code too and I'm seeing the same what you have shown above.

The Geocities script adds an onclick handler to the page, the function cH. If
you click anywhere on the page, this function gets executed.

If the click happened on a link (an <A> tag with a HREF attribute), the function
cH also is called, but the browser does not yet start loading the link's target.
Only when the function has ended, the browser will perform it's normal
'click-on-link' function (i.e. load the target of the link), *unless* the
onclick handler (the function cH in this case) returns false (this signals the
browser to abolish it's normal click-on-link function).
And that's exactly the problem with the cH function when the
top.d.location.href=uHref is executed: location.href tells the browser to goto
the specified link (like typing the URL in the addressbar), but after the line
with top.d.location.href there's no line with "return false", and therefor the
browser's normal 'click-on-link' function also gets executed (which triggers
Moz/FF to display a second download window).
The function cH does have a "return false" statement just above the line with
top.d.location.href. This part of the function is for links which are on the
'geocities.com" domain, and it also explains why you don't get a second download
window with the two other links on your test page. (if you enabled the pretty
print function of the JS debugger it's quite easy to spot).

So, again, it's *not* Mozilla/Firefox, but a flaw in the Geocities script.
>>

So I think then, there is no bug anywhere in Mozilla code and I can close the
bug (I still wondering why IE 6.0 with WinXP SP2 doesn't fail.... but that is a
different history).

Regards,

   Chemi.