338807 - Unable to DLLRegisterServer AccessibleMarshal.dll on trunk builds (C Runtime library error)

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Robert Strong (they/them - no direct email)]

When registering AccessibleMarshal.dll manually or using RegDLL with the NSIS installer this error occurs with trunk builds. I suspect the xpinstall based installer is hiding the error.

Comment 1

[Robert Strong (they/them - no direct email)]

To reproduce run regsvr32 <path to AccessibleMarshal.dll>\AccessibleMarshal.dll

Comment 2

[Aaron Leventhal]

I hate this COM stuff. Do we have to unregister with /u first? Or what?

Comment 3

[Robert Strong (they/them - no direct email)]

Shouldn't have to. I downloaded a build last night to verify the installer work and just ran regsvr32 <path to AccessibleMarshal.dll>\AccessibleMarshal.dll to get the error.

Comment 4

[Aaron Leventhal]

Does it happen when you manually use regsvr32 on a 1.8 branch build?

Comment 5

[Robert Strong (they/them - no direct email)]

No it doesn't.

Comment 6

[Aaron Leventhal]

>> Does it happen when you manually use regsvr32 on a 1.8 branch build?
> No it doesn't.

So to me that means something regressed -- can we get a QA to find the regression window? Otherwise I'm not sure where to start.

Comment 7

[Robert Strong (they/them - no direct email)]

As a starting point I tried the following zip build from 20060430 and it also exhibits this same error when running regsvr32 on AccessibleMarshal.dll
http://mozilla.osuosl.org:80/pub/mozilla.org/firefox/nightly/2006-04-30-05-trunk/firefox-3.0a1.en-US.win32.zip

So, it looks like it has been around for quite some time.

Comment 8

[Robert Strong (they/them - no direct email)]

I suspect this is along the same lines as bug 329237.

Comment 9

[Robert Strong (they/them - no direct email)]

Adding qawanted

If someone could narrow down the regression window it would be appreciated. It has been around since at least 20060430 per comment #7. Thanks

Comment 10

[Robert Strong (they/them - no direct email)]

Attachment: embed the manifest for the dll at id 2

This fixes this bug for me when building with VC 8 on the trunk.

The dll depends on msvcrt but didn't have the manifest embedded. Also, dll's should use a resource id of 2 for the resource in RT_MANIFEST.

Comment 11

[Aaron Leventhal]

Comment on attachment 223250 [details] [diff] [review]
embed the manifest for the dll at id 2

I have no idea what that does. Also don't have sr= status. Sorry, I would have loved to help with a review.

Comment 12

[(not currently active) Ted Mielczarek]

Comment on attachment 223250 [details] [diff] [review]
embed the manifest for the dll at id 2

Since Rob says this DLL lives in the bin directory, it shouldn't have any problems having a manifest embedded.

I can't build a11y to test this, since I only have vctoolkit2k3 / vc8 to build on, but the change makes sense to me.

Comment 13

[Robert Strong (they/them - no direct email)]

Fixed on trunk

Comment 14

[Thomas Schade]

(In reply to comment #13)
> Fixed on trunk

Confirmed for:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060525 Minefield/3.0a1 ID:2006052520 [cairo]
Installer: firefox-3.0a1.en-US.win32.installer-nsis.exe, 26.05.06, 04:06

Comment 15

[Robert Strong (they/them - no direct email)]

As a side note, the XPInstall based installer just logged the error to the installation log without notification.