209806 - MfcEmbed preferences not sticking on restart

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: Packaging, defect)

Description

[Tracy Walker [:tracy]]

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.

Comment 1

[Conrad Carlen (not reading bugmail)]

Doing fresh build. WFM using my build pulled 6/13.

Comment 2

[Cathleen]

anyone else can reproduce this problem with up-to-date trunk build?

Comment 3

[Peter Lubczynski]

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.

Comment 4

[Cathleen]

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.

Comment 5

[Conrad Carlen (not reading bugmail)]

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.

Comment 6

[Adam Lock]

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?

Comment 7

[Tracy Walker [:tracy]]

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
default
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?

Comment 8

[Conrad Carlen (not reading bugmail)]

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?

Comment 9

[Peter Lubczynski]

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.

Comment 10

[Conrad Carlen (not reading bugmail)]

Darin, can you take a look at Peter's last comment?

Comment 11

[Adam Lock]

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.

Comment 12

[Adam Lock]

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.

Comment 13

[Conrad Carlen (not reading bugmail)]

Removing dist/Embed and rebuilding it, I can repro this. Same minimal output on
the ipc deamon console as Adam.

Comment 14

[Conrad Carlen (not reading bugmail)]

The missing piece is: transmngr_client.dll. I'll take it. I thought I had
already fixed this...

Comment 15

[Adam Lock]

Attachment: Sample patch

I was just working on this as you said it Conrad!

Comment 16

[Conrad Carlen (not reading bugmail)]

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?

Comment 17

[Conrad Carlen (not reading bugmail)]

The packaging is OK - some code is using an outdated contract ID.
It turns out to be a prefs bug.

Comment 18

[Darin Fisher]

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!

Comment 19

[Conrad Carlen (not reading bugmail)]

Attachment: patch to use new contract ID

Comment 20

[Conrad Carlen (not reading bugmail)]

Using this patch, and if I delete my component reg, once transmanager_client.dll
is gone, it works.

Comment 21

[Darin Fisher]

Comment on attachment 125961 [details] [diff] [review]
patch to use new contract ID

who is [e-mail]?

Comment 22

[jag (Peter Annema)]

Comment on attachment 125961 [details] [diff] [review]
patch to use new contract ID

r=jag

Comment 23

[Adam Lock]

Comment on attachment 125961 [details] [diff] [review]
patch to use new contract ID

r=adamlock

Comment 24

[Conrad Carlen (not reading bugmail)]

Fixed.

Comment 25

[Tracy Walker [:tracy]]

verified with build 2003-06-20-04-trunk