1921794 - [Solidworks EPDM explorer integration] Out-of-process file-picker crashes

Status: RESOLVED INVALID

(External Software Affecting Firefox :: Other, defect)

Description

[Andy]

Attachment: working-in-edge-chrome.mp4

Steps to reproduce:

In Firefox from a file input, or using File open in the main menu, open a folder that is handled by Solidworks EPDM explorer integration and Firefox gives the message, "The windows file-dialog has crashed. No file or folder could be selected." Attached videosshows it in Firefox 130.0.1, and in nightly 132.0a1

Actual results:

"The windows file-dialog has crashed. No file or folder could be selected."

Expected results:

The folder opens and allows selecting a file as normal (Edge and Chrome work this way).

Comment 1

[Andy]

Attachment: demonstrates explorer issue in FF Nightly

Comment 2

[Andy]

Attachment: demonstrates issue in 133 - with a fresh profiles

Comment 3

[Andy]

To the best of my knowledge this is a new problem in 133, things were working fine before.

Comment 4

[Ray Kraesig [:rkraesig]]

If you go to about:crashes, there should be a number of crash reports there corresponding to these crashes. Can you make sure those have been submitted to our crash-report setup and post their IDs here?

(This is almost certainly a bug in Solidworks' shell-extension DLL, but it would be nice if we could see what they're trying to do.)

Comment 5

[Andy]

I did not know about about:crashes. I have just submitted a crash report with ID bp-0576337f-a67e-4f12-8b89-a1edb0240930

Comment 6

[Ray Kraesig [:rkraesig]]

(In reply to Andy from comment #5)

I did not know about about:crashes.

In an ideal world, you would never need to; but, alas, here we are.

I have just submitted a crash report with ID bp-0576337f-a67e-4f12-8b89-a1edb0240930

Thanks! This is more interesting than I was expecting; the crash is actually a stack overflow(!) in msodbcsql17.dll, documented as being the "Microsoft ODBC Driver for SQL Server", as invoked via odbc32.dll!SQLExecDirectW(), as invoked from StoredProcs.dll!00007ffe384cddf8() (offset 0x0eddf8 in DLL version 30.05.0.62).

None of that is information we at Mozilla can do anything with immediately, but if you can reach out to Solidworks via whatever support channels you have and point them to this Bugzilla page, it should jumpstart their investigation. If Solidworks provides a public link for their issue tracker, please post it here; otherwise, just let us know the issue's been opened. (To any Solidworks engineer(s) reading this: the behavioral change that precipitated this is probably that, by default, we now open file dialogs in a separate instance of firefox.exe. EDIT: This was later found not to be relevant; see comment 15, below.)

For immediate temporary relief, you should be able to go to about:config and set widget.windows.utility_process_file_picker to -1 — we'd like to remove that pref relatively soon, but it will definitely last at least two months. (And if changing that doesn't have any effect we'd like to hear about it!)

Comment 7

[Andy]

Attachment: firefox doesn't show correctly.png

I set widget.windows.utility_process_file_picker to - as instructed and I am able to folder. But it does not behave like it used to - see screenshot firefox doesn't show correctly comparing how it appears in Chrome vs in Firefox. The Solidworks explorer extension doesn't seem to load at all.

Comment 8

[Andy]

Also, I have contacted our Solidworks reseller to get their input and start the process of opening a ticket with Solidworks.

Comment 9

[Ray Kraesig [:rkraesig]]

(In reply to Andy from comment #7)

Created attachment 9428271 [details]
firefox doesn't show correctly.png

I set widget.windows.utility_process_file_picker to - as instructed and I am able to folder. But it does not behave like it used to - see screenshot firefox doesn't show correctly comparing how it appears in Chrome vs in Firefox. The Solidworks explorer extension doesn't seem to load at all.

That's very odd — I wasn't expecting that at all. Could you try to use mozregression to narrow down when that started happening? (You'll need to specify that file-picker preference on the second page of the wizard, but otherwise it should be straightforward.)

Comment 10

[Andy]

Attachment: first bad commit found in mozregression

Comment 11

[Andy]

Attachment: last working commit found in mozregression

Comment 12

[Andy]

Attachment: with process file file picker -1 - back to to 2020 Screenshot 2024-10-01 at 1.34.35 PM.png

Comment 13

[Andy]

Attachment: with process file file picker -1 Screenshot 2024-10-01 at 1.32.21 PM.png

Comment 14

[Andy]

I went through Mozregression and when setting widget.windows.utility_process_file_picker to -1 I could never get the file picker to work as expected. I went back to 2020 and it never properly used the Solidworks extension to display files.

Without the that setting set I could the problem first occurs on the build from 2023-12-01 (2023-11-30 build works).

First time using Mozregression, I hope the screenshots are helpful.

Comment 15

[Ray Kraesig [:rkraesig]]

(In reply to Andy from comment #14)

I went through Mozregression and when setting widget.windows.utility_process_file_picker to -1 I could never get the file picker to work as expected. I went back to 2020 and it never properly used the Solidworks extension to display files.

?! That pref didn't even exist then...

... ah, I see. I incorrectly inferred (but you did not actually state!) that this was a recent issue with Firefox and that it had previously worked correctly. As it happens, if you'd gone back another few months, you'd have found the change -- it was in bug 1468250, where we blocked SolidWorks' DLL because they'd been informed it was crashing Firefox but we'd heard nothing back from them for some months.

However, this block should have been extended to the out-of-process file-dialog (widget.windows.utility_process_file_picker unset) in bug 1901230, and specifically D216327. In fact, it was — we can tell because the associated incoming crashes dropped almost immediately. The crash signature in your crash is very different from the ones reported in those two bugs, though, and somehow it has Database.dll loaded...

:gstoll, would you happen to have any insight here?

Comment 16

[Andy]

FYI - Our support team at GoEngineer created a service request with Solidworks, SR01271827-01. I will update with any information they provide.

Comment 17

[Greg Stoll :gstoll]

Thanks - hopefully they'll be able to fix it on their end.

I don't know why Database.dll seems to be getting through the block. Let me see if I can download a trial version of Solidworks and reproduce the issue.

Comment 18

[Greg Stoll :gstoll]

Unfortunately there doesn't seem to be a trial version available for download.

As you've filed a support ticket with Solidworks, I think that's the best way to try to proceed here. Thanks!