134754 - Needs scriptable API to get Win32 registry entry

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Bill Law]

In order to greatly simplify the implementation of various Win32-specific 
features, we need a simple means to access, from JavaScript code running in the 
chrome, Win32 registry contents.

The alternative (lack of this feature) requires that such features be 
implemented in C++ which requires a separate interface declaration, source 
file, makefile, etc.

I will attach shortly a patch that adds the new method.

Comment 1

[Bill Law]

Attachment: Patch to add new method declaration and implementation

Note that this patch also removed some cruft from the implementation file
(obsolete Win32 shell programming stuff that is no longer used).

Comment 2

[Bill Law]

Nominating.  Needed for bugscape bug 12434.

Comment 3

[timeless]

if i want to set HCCR for the current user instead of for the OS, can I? And 
vice versa? [this is an NT question]

Comment 4

[Daniel Veditz [:dveditz]]

Why would someone only ever want to read string values from the windows
registry? Sure, it's useful, but I bet this leaves a lot of people wanting a lot
more.

If we're going to try to shoehorn this in to 1.0 it'd be better to come up with
a separate and useful windows registry interface, even if the implementation for
everything but GetvalueString is "return NS_ERROR_NOT_IMPLEMENTED;"

Comment 5

[Samir Gehani]

Nav triage team: nsbeta1+/adt1

Comment 6

[Bill Law]

Attachment: Revised patch to put new method into a new interface

Is that better?  I'm not quite sure how to state that this new interface isn't
fully cooked yet.

Comment 7

[Bill Law]

So what additional methods need to be added?  At a minimum, some sort of 
setRegistryEntry.  But I'd think we'd also want registry enumeration methods 
and those would probably have to return an enumerator of some sort that 
generates nsIWindowsRegistryKey objects or some such.

There's a fair bit of complexity in the Win32 registry APIs and I'm not sure 
how much of that to expose, given that we won't actually be implementing any of 
it.  Please advise.

Comment 8

[David Majda]

Attachment: Delhpi TRegistry class - inspiration

As a help I am attaching declaration of a class, that encapsulates Registry API
in Borland Delphi. You can find there some inspiration what to implement, I
hope.

Comment 9

[Samir Gehani]

Comment on attachment 78000 [details] [diff] [review]
Revised patch to put new method into a new interface

r=sgehani

Comment 10

[scottputterman]

What is the bug that the user sees because of this?

Comment 11

[Samir Gehani]

Regarding comment 10: this is required for
<http://bugscape/show_bug.cgi?id=12434> which is a Mach V stop ship bug.

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 78000 [details] [diff] [review]
Revised patch to put new method into a new interface

sr=dveditz

Comment 13

[Bill Law]

Attachment: test case (xul dialog)

This .xul file can be used to test this code.  I've used it from a local file
(specify 'mozilla -chrome "file:///c|/path/registry.xul"'.  I'm not sure how it
might behave differently if you try to open it via the attachment link in the
bug.

Comment 14

[Peter Trudelle]

optimistically updating eta to today, ->1.0

Comment 15

[Phil Schwartau]

Bill: I'm looking at your registry.xul testcase in Comment #13.
On my WinNT box, I have a Registry key 

          HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Desktop

and under this I see, for example, this name-value pair:

                   haveBeenSet       1


How do I use the testcase on this? Here's what I'm assuming:

1. Select the HKEY_LOCAL_MACHINE radio button
2. Enter "SOFTWARE\Mozilla\Desktop" in the |Subkey| textbox
  (no leading or trailing slashes)
3. Enter "haveBeenSet" in the |Value| textbox
4. Click the |Get it| button
5. Then the value "1" should appear in the greyed-out textbox
   to the right of the "Get it" button
 

Are these steps correct? I'm particularly unsure of step 3.
Does "haveBeenSet" belong in the |Subkey| testbox instead?

Comment 16

[scottputterman]

marking [adt1 rtm].  This is not a beta stop ship bug.  If you can get this
patch ready soon, please nominate it with the adt1.0.0 keyword.  Otherwise,
let's get this in rtm.

Comment 17

[Peter Trudelle]

fixed

Comment 18

[Peter Trudelle]

nominating for branch checkin

Comment 19

[scottputterman]

adding adt1.0.0+ for checkin to the 1.0 branch.  Please get drivers approval and
then checkin.  This could wait until after Mozilla1.0 ships and then get into
the Mach V rtm.

Comment 20

[Bill Law]

Attachment: test case (updated)

Phil, there was a bug in the test case I attached previously (it always fetched
from HKEY_CLASSES_ROOT).  I've attached the fixed version.

Comment 21

[Christine Wozniak]

Adding custrtm+; might have customization impact.

Comment 22

[scottputterman]

changing to adt1.0.1+ for checkin to the 1.0 branch.  Please get drivers
approval before checking in.

Comment 23

[Judson Valeski]

this seems scary on the surface. cc'ing mstoltz. can a website randomly access
my registry entries?

Comment 24

[Mitchell Stoltz (not reading bugmail)]

Looks like this functionality is accessible only to chrome, not to Web content,
so it's safe. Allowing web pages to access the Windows registry would be very
bad, but that doesn't seem to be the case here. Creating a scriptable XPCOM
interface doesn't automatically expose the interface to untrusted Web content
unless you're adding it to the DOM or take some other explicit steps.

Comment 25

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1"
keyword and add the "fixed1.0.1" keyword.

Comment 26

[Paul Wyskoczka]

Bill, can you check this fix in when the tree opens.  Thx

Comment 27

[scottputterman]

Does this still need to be checked in to fix the bugscape bug?

Comment 28

[Bill Law]

Updating mozilla1.0.1+->fixed1.0.1 (which I keep wanting to forget)

Comment 29

[Terri Preston]

Verified Win XP branch build 2002071808