Closed
Bug 234192
Opened 20 years ago
Closed 20 years ago
Visio file in filepicker crashes mozilla
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: Deinst, Assigned: timeless)
References
Details
(Keywords: crash)
Attachments
(2 files)
19.93 KB,
application/vnd.visio
|
Details | |
3.52 KB,
patch
|
deanis74
:
review+
rbs
:
superreview+
|
Details | Diff | Splinter Review |
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•20 years ago
|
||
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•20 years ago
|
||
Comment 4•20 years ago
|
||
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.
if you want to take the easy route, just mark this wontfix :)
Comment 10•20 years ago
|
||
I agree with making this a won't fix. I could do this in pretty much any application.
Comment 11•20 years ago
|
||
so is this "not a bug" then? Can it be resolved as invalid or wontfix?
Comment 12•20 years ago
|
||
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 | ||
Comment 13•20 years ago
|
||
Assignee | ||
Comment 14•20 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 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 15•20 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.
Comment 16•20 years ago
|
||
hmm, does -fexceptions change the ABI of code?
Comment 17•20 years ago
|
||
(In reply to comment #16) > hmm, does -fexceptions change the ABI of code? nevermind, for the plugins code this obviously works.
Comment 18•20 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+
Assignee | ||
Comment 19•20 years ago
|
||
is a MessageBox ok w/ everyone? I wasn't sure what kind of output people would want.
Attachment #145310 -
Flags: superreview?(ere) → superreview?(roc)
Comment 20•20 years ago
|
||
MessageBox would be ok with me.
Comment 21•20 years ago
|
||
ditto
Attachment #145310 -
Flags: superreview?(roc) → superreview?(rbs)
Comment 22•20 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 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+
Assignee | ||
Comment 23•20 years ago
|
||
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
Assignee | ||
Comment 24•19 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.
Description
•