Problems with nsIDOMHTMLInputElement::SetValue(), pathnames validation, security issues?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Problems with nsIDOMHTMLInputElement::SetValue(), pathnames validation, security issues?

Babele Dunnit
Hi all,

I am experiencing a problem with "<input> type=file" nodes, i.e. nsIDOMHTMLInputElement. In our application, which is an eye-tracker controlled browser using an embedded Gecko7, when an user selects one of those nodes a custom "file choose dialog" appears. I let the user interact and choose a file with a valid pathname, and then I set the pathname on the selected nsIDOMHTMLInputElement via SetValue() in order to show it in the browser window. It works, but after a few event loops, Gecko resets the vaue to a null string. I mean, I can see the selected pathname for a frame or two in the editbox, and then it disappears.

I noticed that nsIDOMHTMLInputElement does some validation to the string you pass to his SetValue() method, i.e. it checks for a valid pathname ("pippo" will not work, while "/pippo" does) and I am wondering if I am hitting some security issue here. Should I tell Gecko in some way where and how to find "valid" pathnames, which can be accepted by nsIDOMHTMLInputElement::SetValue()? Do I have to call some other "path validation" method beforehand?

Please note that this stuff is working OK with Gecko7 embedding under Windows, but is broken with Gecko7 embedding in our Linux port, so I am quite positive about something security-related in Linux (which I admittedly do not know so much) and/or Gecko Linux/GTK version.

here is a link to a small test page I did to check this stuff:

https://dl.dropbox.com/u/692299/UploadTest.htm

Any Hints Welcome,
Thanks, Aaron



_______________________________________________
dev-embedding mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-embedding