Closed Bug 209806 Opened 21 years ago Closed 21 years ago

MfcEmbed preferences not sticking on restart


(Core Graveyard :: Embedding: Packaging, defect)

Other Branch
Windows 2000
Not set


(Not tracked)



(Reporter: tracy, Assigned: ccarlen)



(1 file, 1 obsolete file)

seen with recent builds of windows embedding app.

-launch app
-change homepage in prefs
-restart app

homepage entered previously is gone.  default homepage is displayed
 this was seen before in bug 204740. 

I thought bug 205955 was causing this with recent builds.  but I am no longer
seeing that bug.
Doing fresh build. WFM using my build pulled 6/13.
anyone else can reproduce this problem with up-to-date trunk build?
yeah, I can repro in a debug trunk build I just made this morning. I can also
repro on a tree from two weeks ago so it sounds like this isn't new.

Going back to the prefs window after dismissing the dialog but before the
restart shows the new home page as does clicking on the toolbar. However, after
restart, I'm back to the embedding home page.
sounds like this shouldn't be a bloker if a 2-week old tree has the same issue.

we should get this fixed soon.  downgrade to critical.

Severity: blocker → critical
Peter: Which dir are you running mfcEmbed from - dist\bin or dist\Embed? From
the build I just did, WFM from dist\bin. I tried with both an existing profile
and after wiping mfcEmbed's app data.
I see this with an Embed build. There is also an assertion at shutdown:

###!!! ASSERTION: no xpcom-shutdown event??: 'mTransport == nsnull', file c:/m/s
ource/mozilla/ipc/ipcd/client/src/ipcService.cpp, line 167

Perhaps the prefs are not being written?
I was wondering if this bug might be related to the way I have to install.
Trying to run mfcembed after installing the GRE and mfcembed to the installer
locations doesn't work. Since the change was made to the GRE installer that
won't allow any place but the default install location, I've had to hand copy
the files over to the location of the mfcembed installation.  Is this, in some
way, messing with the apps ability to save the chosen prefs on exit?
Adam, or Peter: when I change the homepage pref in mfcEmbed (running from
dist\Embed) the prefs file is written out immediately. I see msgs in the ipc
daemon's console window about acquiring and releasing the lock for prefs. Are
you seeing this? Are you even seeing a console for the ipc daemon?
I'm running mfcembed.exe from /bin and I also see the mozipcd console window on
startup but nothing spits out on changing the home page. After exiting, it
remains open. I've tried both killing it and leaving it open when restarting
with no luck but it doesn't seem to go away on its own.
Darin, can you take a look at Peter's last comment?
The entire output of this window is:

$$$ ipcLockModule_Init
$$$ ipcLockModule_ClientUp [1]
$$$ ipcLockModule_ClientDown [1]

It doesn't print anything when I change the pref at all.
The embedding dist does appear to be missing the ipcd.xpt file but adding this
to Embed/components makes no difference. I'm wondering if there might be another
manifest problem, e.g. a missing component which is causing this to fail.
Removing dist/Embed and rebuilding it, I can repro this. Same minimal output on
the ipc deamon console as Adam.
The missing piece is: transmngr_client.dll. I'll take it. I thought I had
already fixed this...
Assignee: adamlock → ccarlen
Component: Embedding: APIs → Embedding: Packaging
Attached patch Sample patch (obsolete) — Splinter Review
I was just working on this as you said it Conrad!
Hey, I had fixed it. Then darin removed it :-) Was that an accident, or was the
transmngr_client moved into ipcdc.dll and some code is using an outdated
contract ID?
The packaging is OK - some code is using an outdated contract ID.
It turns out to be a prefs bug.
This is a regression from my changes for bug 204255 back in May!  Not sure how
my search missed the contract ID... sorry for the trouble!
Attachment #125948 - Attachment is obsolete: true
Using this patch, and if I delete my component reg, once transmanager_client.dll
is gone, it works.
Attachment #125961 - Flags: superreview?(darinf)
Attachment #125961 - Flags: review?(adamlock)
Attachment #125961 - Flags: superreview?(darin)
Comment on attachment 125961 [details] [diff] [review]
patch to use new contract ID

who is
Attachment #125961 - Flags: superreview?(darinf)
Attachment #125961 - Flags: superreview?(darin)
Attachment #125961 - Flags: superreview+
Comment on attachment 125961 [details] [diff] [review]
patch to use new contract ID

Attachment #125961 - Flags: review+
Comment on attachment 125961 [details] [diff] [review]
patch to use new contract ID

Attachment #125961 - Flags: review?(adamlock)
Closed: 21 years ago
Resolution: --- → FIXED
verified with build 2003-06-20-04-trunk
Keywords: smoketest
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.