8.17 KB, image/gif
23.87 KB, application/x-xpinstall
11.75 KB, application/x-xpinstall
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Cannot open VSD files (Visio) file via gmail. After clicking on the vsd file the download pop up appears without any download button, so even if user wants to open the file there is no open/download file button.***Please note that the same vsd file opens perfectly with Explorer (as well as with previous Firefox versions). Reproducible: Always Steps to Reproduce: 1. Try opening a vsd file via gmail with Firefox 3 2. 3. Have a pop up prompting to open/download the vsd file (which would include a download or open button)
not a security bug
This is worksforme, using current trunk build. What kind of download popup are you exactly seeing? Could you perhaps attach a screenshot of that to this bug?
Created attachment 327693 [details] Screenshot with of the Download popup - hard to believe but there's no download button Martijn Wargers has asked for a screen shot - here it is, hope this helps :-)
For some reason, the download window seems clipped when looking at that screenshot. It looks like you have BitComet installed, what happens if you uninstall the BitComet extension? Does that help?
Hi, I know the download window looks clipped but - I didn't clip it!!! - I contacted you guys to let you know that there's a bug - not to waste either of our time. As a HiTech project manager, if I were you guys I'd conduct real environment testing by simply sending myself a VSD doc (along with BitComet installed) instead of asking the client to conduct the QA integration. And yes I do have BitComet installed - Why would I want to uninstall it? Sorry that's not a solution.
Well, I didn't know the download window was clipped. Your screenshot made that clear. So thanks for that. Fwiw, I did install BitComet and did send a VSD doc to myself, but I couldn't reproduce the issue. So I just simply don't know how to reproduce this issue.
I see, so now I won't ever be able to open VSD files using Firefox 3 while I had no problems opening VSD files on the previous Firefox version. Thanks - great solution...
Ok, I'm seeing it now, with: http://martijn.martijn.googlepages.com/unknowncontenttype.exe This regressed between 2008-03-13 and 2008-03-14: 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=2008-03-13+04&maxdate=2008-03-14+09&cvsroot=%2Fcvsroot I think it's somehow a regression from bug 422585.
Status: UNCONFIRMED → NEW
Component: File Handling → Download Manager
Ever confirmed: true
QA Contact: file.handling → download.manager
Created attachment 328201 [details] Bit comet extension that's needed for the bug to appear I haven't been able to make a standalone testcase that triggers the bug. This is the extension in question (without the binary component), that is needed to trigger the bug.
Created attachment 328202 [details] [diff] [review] patch? This fixes the bug, maybe this is good enough as a workaround for now? I would think that sizeToContent() would flush layout already.
(In reply to comment #8) > I think it's somehow a regression from bug 422585. Nope. That just reverts a line of code changed by a previous checkin, which caused the DM window to fail to init fully. It's possible an uninitialized window was masking a problem introduced by some other bug, though.
Comment on attachment 328202 [details] [diff] [review] patch? I'm not the right person to review this. sdwilsh is probably who you want, and he's going to ask for tests. :)
Or at least an explaination as to *why* that fix actually fixes the bug. A test would be awesome though (and this looks testable).
Created attachment 328487 [details] fix by extension Sorry, I was wrong, actually. The patch doesn't work. It seems that doing the sizToContent() after another timeout, fixes the issue. I noticed that currently, sizeToContent() is called when the overlayed content hasn't been merged yet. No idea why that's happening. Jacky, does this extension fix the issue for you? It does seem to fix it for me. You probably need to save the file first and then install it locally.
Attachment #328202 - Attachment is obsolete: true
What extensions do you have installed?
The Bitcomet extension.
This feels a lot like bug 427044
Well, this is certainly not invalid.
Until we identify what in the add-on is causing the dialog to get cut-off, this isn't blocking.
Flags: blocking1.9.1? → blocking1.9.1-
The overlay in the add-on is causing it, see comment 14. In any case, this isn't a problem with the extension, it's a problem with Firefox.
The problem is that we see this file type as executable, so we are trying to force the save UI because, for security reasons, we only allow users to save executable files. I'm going to assert that this is either a dupe of bug 427044 or it is also INVALID.
It's fine to only allow users to save executable files, that's not the issue here. The issue is that the download box is cut off, when it shouldn't.
And the UI is drawn like that because we think the file is an executable file, so we use the minimal UI. I don't know how the extension is trying to override the restriction of not opening executable files.
The extension isn't trying to override anything, it's just adding an overlay to the download dialog, that adds some extra option (in the bitcoment case the "Download this file with BitComent".
You need to log in before you can comment on or make changes to this bug.