Closed Bug 234192 Opened 20 years ago Closed 20 years ago

Visio file in filepicker crashes mozilla

Categories

(Core :: XUL, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: Deinst, Assigned: timeless)

References

Details

(Keywords: crash)

Attachments

(2 files)

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.
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
Does this not happen with notepad?
It sure does happen with Notepad, too. I guess it's good that I'm not canconfirm.
this is so not our fault :).

that said, perhaps we can handle it. asking around before killing.
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.
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.
Well sure, if you want to take the easy route.  :)
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.
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
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.
Assignee: jag → timeless
Status: NEW → ASSIGNED
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 ...
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 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 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+
is a MessageBox ok w/ everyone? I wasn't sure what kind of output people would want.
Attachment #145310 - Flags: superreview?(ere) → superreview?(roc)
MessageBox would be ok with me.
ditto
Attachment #145310 - Flags: superreview?(roc) → superreview?(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.
Attachment #145310 - Flags: superreview?(rbs) → superreview+
Keywords: crash
mozilla/widget/src/windows/nsFilePicker.cpp 	1.75
mozilla/widget/src/windows/Makefile.in 	3.18
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: