283308 - Download manager opens when using swipe card to login

Status: RESOLVED EXPIRED

(Toolkit :: Downloads API, defect)

Description

[Nick]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0

On our web based EPOS system we are using Mozilla due to its security features, 
The hardware we use has an integrated Magnetic stripe swipe card reader for which 
we encode the usernames/passwords to enter the system automatically. It works
except that every single swipe opens a new Download manager window - I habut as
it does not actually download anythingvetr theied se DM after download complete"
this does not work, I have tried all sorts of things but to no avail The ideal
fix would be to completely turn off the download manager, make it an optional
install - I have removed every segment of the DManager but I still get left
with the title bar with the close button.

Reproducible: Always

Steps to Reproduce:
1.Swwipee  acardd through the card reader
2.Download manager opens but does not close even though it is set to do so in
the options
3.Have to manually close it but this defeats the whole object of our EPOS system
being "Fast"



Expected Results:  
Number enter and person is logged in, without any popup windows download manager etc

tried all sorts of themes, tweaked the card reader settings tried all of the
options close when complete etc, deleted various components to the point where
just the title bar opens.... if could get rid of this woulldd be  fine but must
be an easier fix or a patch available

Comment 1

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050227
Firefox/1.0+

I don't quite see what is happening. Downloads usually occur when the MIME type
sent by the server is one can that cannot be handled by the browser.

Is there a server involved?

Is the hardware mimicking a keyboard and sending a return or tab that triggers
a submit or jaavascript (that starts the download)?

Do you actually want a download? Is there a server-side solution?

Comment 2

[Nick]

(In reply to comment #1)
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) 
Gecko/20050227
> Firefox/1.0+
> I don't quite see what is happening. Downloads usually occur when the MIME 
type
> sent by the server is one can that cannot be handled by the browser.
> Is there a server involved?
> Is the hardware mimicking a keyboard and sending a return or tab that 
triggers
> a submit or jaavascript (that starts the download)?
> Do you actually want a download? Is there a server-side solution?

Comment 3

[Nick]

(In reply to comment #1)
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) 
Gecko/20050227
> Firefox/1.0+
> I don't quite see what is happening. Downloads usually occur when the MIME 
type
> sent by the server is one can that cannot be handled by the browser.
> Is there a server involved?
> Is the hardware mimicking a keyboard and sending a return or tab that 
triggers
> a submit or jaavascript (that starts the download)?
> Do you actually want a download? Is there a server-side solution?



Yes: the card is mimicking a keyboard (so that other uses can't see the 
numbers a user presses)
Yes: There is a server, running the app which is PHP based.
No: There is no download requested.

There is no javascript execution, but card readers by default have a begin 
command and end command like % and ? - We have set the app server side to 
ignore this. FYI the last button that would normally be pressed instead of 
using the swipe is a "Go" button - our developers have replicated this 
function server side as a carriage return.
Not overly sure on the mime type, the app is recent and developed around css 
sheets.

If there is any other info I can give, let me know.

The cards work fine when used with MSIE - the relevence... I dont know.

Cheers

Comment 4

[Ben Fowler]

That is a lot clearer. 

I am working on the basis that the last character sent by hardware is a carriage
return which triggers a form submit.

I think you need to know the exact HTTP request sent by the browser, and 
what headers are sent back by the server. 

I would be tempted you to check with ethereal. You may have a better way. Are 
you able to do this and/or have your developers do it?

If it matters, are you able to see the contents of the downloaded files?

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.