234192 - Visio file in filepicker crashes mozilla

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[David Einstein]

User-Agent:       
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.

Comment 1

[Robert Accettura [:raccettura]]

Reporter:  A testcase, or website, or something where one could easly see what
your seeing would help.

Comment 2

[Peter Zillmann]

Attachment: Visio VDX file which can be used to reproduce the bug

Comment 3

[timeless]

Does this not happen with notepad?

Comment 4

[Peter Zillmann]

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

Comment 5

[timeless]

this is so not our fault :).

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

Comment 6

[:deanis74]

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

[timeless]

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

[:deanis74]

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

Comment 9

[timeless]

if you want to take the easy route, just mark this wontfix :)

Comment 10

[Robert Accettura [:raccettura]]

I agree with making this a won't fix.

I could do this in pretty much any application.

Comment 11

[Asa Dotzler [:asa]]

so is this "not a bug" then? Can it be resolved as invalid or wontfix?

Comment 12

[Robert Accettura [:raccettura]]

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
effort?  

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

[timeless]

Attachment: draft (based on plugins code) -uwp13

Comment 14

[timeless]

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
first.

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

the non -w of course indents the nested code ...

Comment 15

[Ere Maijala (slow)]

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.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm, does -fexceptions change the ABI of code?

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #16)
> hmm, does -fexceptions change the ABI of code?

nevermind, for the plugins code this obviously works.

Comment 18

[:deanis74]

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.

Comment 19

[timeless]

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

Comment 20

[Ere Maijala (slow)]

MessageBox would be ok with me.

Comment 21

[:deanis74]

ditto

Comment 22

[rbs]

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

Although exceptions are discouraged, it seems unavoidable here, and is
platform-specific.
http://www.mozilla.org/hacking/portable-cpp.html#dont_use_exceptions
sr=rbs, based on your comments that a similar stuff was needed to bullet-proof
plugins.

Comment 23

[timeless]

mozilla/widget/src/windows/nsFilePicker.cpp 	1.75
mozilla/widget/src/windows/Makefile.in 	3.18

Comment 24

[timeless]

*** Bug 293885 has been marked as a duplicate of this bug. ***