Visio file in filepicker crashes mozilla




15 years ago
14 years ago


(Reporter: Deinst, Assigned: timeless)



Windows XP

Firefox Tracking Flags

(Not tracked)



(2 attachments)



15 years ago
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20030113

This may be a dup of something I submitted earlier today, but I have not gotten 
confirmation in more than an hour for the previus submission.

When a .vdx file appears in the filepicker mozilla occasionally dissapears in a
puff of logic when the cursor passes over the filename.  This appears to happen
as the filepicker is about to display the tooltip describing the file type,
size, date information.  

It only seems to happen on machines that have Visio installed (.vdx is a Visio
XML format save file.)

It appears to be timing related.  It almost always happens with files on our
network file server, but will happen with files on the local machine if you gan
get the mouse to move to the file fast enough.  It seems to happen more
regularly in directories with lots of files.

It is particularly annoying when it happens when attaching files to emails.

Reproducible: Sometimes
Steps to Reproduce:
1. Start Mozilla on a machine that has Visio
2. Menu File > Open File
3. Change to a directory containing a .vdx file
4. hover the mouse over the .vdx file in the file picker
Actual Results:  
Mozilla dissapers.  No crash dialog.  Mozilla is no longer in the process list.
It's gone. 

Expected Results:  
Displayed a box containing file information.
Reporter:  A testcase, or website, or something where one could easly see what
your seeing would help.
Summary: Visio file in filepicker crashes mozilla → Visio file in filepicker crashes mozilla

Comment 2

15 years ago
Created attachment 141355 [details]
Visio VDX file which can be used to reproduce the bug

Comment 3

15 years ago
Does this not happen with notepad?

Comment 4

15 years ago
It sure does happen with Notepad, too. I guess it's good that I'm not canconfirm.

Comment 5

15 years ago
this is so not our fault :).

that said, perhaps we can handle it. asking around before killing.

Comment 6

15 years ago
We may be able to hook the dialog and cancel the tooltip before it pops up, but
I'd rather this was fixed at the source than we work around it.

Comment 7

15 years ago
i was thinking more along the lines of adding an exception handler to catch
crashes from such things and continue along. we do that with plugins.

Comment 8

15 years ago
Well sure, if you want to take the easy route.  :)

Comment 9

15 years ago
if you want to take the easy route, just mark this wontfix :)
I agree with making this a won't fix.

I could do this in pretty much any application.

Comment 11

15 years ago
so is this "not a bug" then? Can it be resolved as invalid or wontfix?
If anything, wontfix.

But since  Dean Tessman and Timeless both have proposals, wouldn't it be best to
just leave this assigned to nobody, unless they both decide it's not worth the

This technically does cause an unexpected (to the enduser) crash, so it's not
invalid, or WFM.

Just my $0.02, but anything that prevents the user from being able to crash
firefox isn't a bad idea.  Even if this isn't a high priority, perhaps leave it
open for when it does become a priority.

Comment 13

15 years ago
Created attachment 145310 [details] [diff] [review]
draft (based on plugins code) -uwp13


15 years ago
Assignee: jag → timeless

Comment 14

15 years ago
Comment on attachment 145310 [details] [diff] [review]
draft (based on plugins code) -uwp13

ere isn't an sr, but ere is the module owner, so this change is ere's to veto.
i'll request a real sr if people sign off on this change. i'm seeking feedback

yes this goes against other views i have in other places, call me a hypocrite

the non -w of course indents the nested code ...
Attachment #145310 - Attachment description: draft (based on plugins code) → draft (based on plugins code) -uwp13
Attachment #145310 - Flags: superreview?(ere)
Attachment #145310 - Flags: review?(dean_tessman)

Comment 15

15 years ago
Comment on attachment 145310 [details] [diff] [review]
draft (based on plugins code) -uwp13

The idea is ok, but I think the user should be told that the dialog was
"unexpectedly closed by Windows" or something.
hmm, does -fexceptions change the ABI of code?
(In reply to comment #16)
> hmm, does -fexceptions change the ABI of code?

nevermind, for the plugins code this obviously works.

Comment 18

15 years ago
Comment on attachment 145310 [details] [diff] [review]
draft (based on plugins code) -uwp13

I agree with Ere.  r=me with the addition of a message to the user.
Attachment #145310 - Flags: review?(dean_tessman) → review+

Comment 19

15 years ago
is a MessageBox ok w/ everyone? I wasn't sure what kind of output people would want.


15 years ago
Attachment #145310 - Flags: superreview?(ere) → superreview?(roc)

Comment 20

15 years ago
MessageBox would be ok with me.

Comment 21

15 years ago


15 years ago
Attachment #145310 - Flags: superreview?(roc) → superreview?(rbs)

Comment 22

15 years ago
Comment on attachment 145310 [details] [diff] [review]
draft (based on plugins code) -uwp13

Although exceptions are discouraged, it seems unavoidable here, and is
sr=rbs, based on your comments that a similar stuff was needed to bullet-proof
Attachment #145310 - Flags: superreview?(rbs) → superreview+


15 years ago
Keywords: crash

Comment 23

15 years ago
mozilla/widget/src/windows/nsFilePicker.cpp 	1.75
mozilla/widget/src/windows/ 	3.18
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 24

14 years ago
*** Bug 293885 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.