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.
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 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.
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+
mozilla/widget/src/windows/nsFilePicker.cpp 1.75 mozilla/widget/src/windows/Makefile.in 3.18
Status: ASSIGNED → RESOLVED
Last Resolved: 15 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.