326013 - profile name not used

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GTK Widget, defect, P2)

Description

[Christian Persch (GNOME) (away; not receiving bug mail)]

EmbedPrivate::SetProfilePath(const char *aDir, const char *aName)

  nsresult rv =
    NS_NewNativeLocalFile(nsDependentCString(aDir), PR_TRUE, &sProfileDir);

This needs to sProfileDir->Append(nsDependentCString(aName)), I guess.

Comment 1

[Benjamin Smedberg]

We don't need profile names any more, so we (correctly) ignore the name parameter.

Comment 2

[Christian Persch (GNOME) (away; not receiving bug mail)]

You may not "need" them anymore technically, but it's still needed for backward compatibility with existing profiles.

Comment 3

[Benjamin Smedberg]

Why? I'm confused... as long as the path is correct, what do we need the name for?

Comment 4

[Christian Persch (GNOME) (away; not receiving bug mail)]

API compatibility. Otherwise implementors have to 

#if HAVE_GECKO_1_9
gtk_moz_embed_set_profile_path("/path/to/profile/name", NULL);
#else
gtk_moz_embed_set_profile_path("/path/to/profile", "name");
#endif

which they may not know, and wonder why it doesn't work. I know I was puzzled why my profile didn't load.

Comment 5

[Benjamin Smedberg]

Wow, you mean the dir passed in was the parent dir? Is there any salting involved (asdfvbjk.slt subdirectories or whatnot)?

Comment 6

[Christian Persch (GNOME) (away; not receiving bug mail)]

Yes, it's the parent directory. So passing ("/path","name") created the profile directory "/path/name/".

Existing gtkmozembed profiles are unsalted, bug 296436.

Comment 7

[Benjamin Smedberg]

Attachment: Append profile name, rev. 1

Comment 8

[Benjamin Smedberg]

Fixed on trunk.