Minotaur - Re-running tool on a second run does not output default bookmarks on FFx 3b2+

RESOLVED FIXED

Status

defect
P1
normal
RESOLVED FIXED
12 years ago
Last year

People

(Reporter: cmtalbert, Assigned: cmtalbert)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Assignee

Description

12 years ago
Running minotaur on a secondary run does not cause the default bookmarks to be generated.

== Steps ==
1. Run Minotaur (Create MinotaurTestProfile (in standard profile location), launch firefox, export bookmarks)
2. Delete the MinotaurTestProfile directory, but do not remove the entry for MinotaurTestProfile from profiles.ini
3. Run Minotaur again (Create MinotaurTestProfile (succeeds in being created), launch Firefox, export bookmarks)

== Actual ==
On the second run, the default set of bookmarks are not generated.

== Expected ==
You'd think that since the new profile was "created" the default bookmarks would be generated.

And, you can do this with your very own Firefox nightly:
1. Firefox -CreateProfile foo
2. Firefox -P foo
3. Note that you have your default bookmarks, the bookmarks toolbar is properly populated
4. Delete the foo profile from the profile directory
5. Firefox -CreateProfile foo
6. Firefox -P foo
7. Note that in this new profile you DON'T have your default bookmarks generated AND note that the bookmarks toolbar is empty.

@Seth, Robcee: Is this a Firefox Bug?  Or is this some other new behavior I need to work around.

I'm really thinking that this is a Firefox bug.

If this is a Firefox bug, then it is a beta 3 blocker because it breaks the minotaur L10N test.
I bet Clint meant to CC sspitzer and not me. ;)

Comment 2

12 years ago
Maybe Dietrich can add information about places migration/setup code, too.
I tried the steps under "with your very own Firefox nightly", but substituted Firefox 2.0.0.11, as Clint requested, on both Vista and Windows XP.

C:\Program Files\Mozilla Firefox>firefox.exe -createProfile foo
C:\Program Files\Mozilla Firefox>firefox.exe -P foo

I then shut down Firefox, and manually deleted the "bfd6wkqk.foo" directory in C:\Users\mozilla\AppData\Roaming\Mozilla\Firefox\Profiles

Next, I did:

C:\Program Files\Mozilla Firefox>firefox.exe -createProfile foo
C:\Program Files\Mozilla Firefox>firefox.exe -P foo

And verified that the profile came up, with default bookmarks (including the "Getting Started" link and the "Latest Headlines" RSS feed on the Bookmarks Toolbar)
looks like bug 381365 might fix this.
Assignee

Comment 5

12 years ago
(In reply to comment #4)
> looks like bug 381365 might fix this.
> 

Thanks Dietrich, I'll try out the patch on that bug and let you know if it fixes this issue (if it does, I'll dupe this bug too).

Assignee

Comment 6

12 years ago
Dietrich, bug 381365 does not fix this, but it does change the behavior. Here's what happens now:
1. firefox - CreateProfile foo
2. firefox -P foo

-> Default bookmarks generated, firefox starts.

3. Delete the "foo" profile directory from the system, but do not change profiles.ini
4. firefox -P foo

-> Get a message stating that firefox is already running, which is not true.
Note that if I follow the above steps and replace "foo" with "bar" (where bar is an already existing profile) in step 4, then firefox will open normally.

= Expected = 
Firefox should start after step 4 and regenerate all the default bookmark data in profile "foo".

I will cross-post this to bug 381365, on the chance that these are related.
Assignee

Comment 7

12 years ago
Drivers:  This does appear to be a regression from Firefox 2.x. (per comment 3).  Minotaur is a test application that we are using to test/track/capture preference, search string, bookmark, and extension changes for L10N and Partner build defaults between versions of Firefox. The L10N team wanted to do a complete baseline of tests for beta3 to see where things stand (as compared to beta 2). 

Then going forward with beta 4, the L10N team would be able to use this beta 3 baseline to see which locales are getting ready/making changes to their defaults. And they would be better able to manage that process.

However, this bug inhibits our ability to create this baseline.

Can we fix this issue for beta 3?
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9beta3
As much as I'd like to, the scope of the problem is unknown, so I'm not comfortable blocking this beta for it. Let's move the target to Beta 4 so that we can use it for the future milestones.
Flags: blocking1.9? → blocking1.9+
Target Milestone: mozilla1.9beta3 → mozilla1.9beta4
Assignee

Comment 9

12 years ago
This patch will work around the problem by always ensuring that we use a unique profile name for each run of minotaur.  I also ran into some update dialog on open when working with older builds so I editing user.js to prevent those modal dialogs from occuring and stopping minotaur's progress.
Assignee: nobody → ctalbert
Status: NEW → ASSIGNED
Attachment #303639 - Flags: review?(anodelman)
Comment on attachment 303639 [details] [diff] [review]
Patch to work around this problem in firefox

parseProfile can be dropped in favor of:

ProfileDir=$($fxdir/$FFX_EXE -CreateProfile $profileName | sed -e "s/.*at '\(.*\)[\/|\\]prefs\.js.*/\1/")

That will strip the directory path from the output of createProfile.  I think that that is cleaner than having to create a whole new script and passing around info into temporary text files.
Attachment #303639 - Flags: review?(anodelman) → review-
Moving bugs that aren't beta 4 blockers to target final release.
Target Milestone: mozilla1.9beta4 → mozilla1.9
Assignee

Comment 13

12 years ago
(In reply to comment #11)
> (From update of attachment 303639 [details] [diff] [review])
> parseProfile can be dropped in favor of:
> 
> ProfileDir=$($fxdir/$FFX_EXE -CreateProfile $profileName | sed -e "s/.*at
> '\(.*\)[\/|\\]prefs\.js.*/\1/")
> 
> That will strip the directory path from the output of createProfile.  I think
> that that is cleaner than having to create a whole new script and passing
> around info into temporary text files.
Alice, I have put this change in but it doesn't work.  ProfileDir is empty after the line is executed.  As far as I'm able to decipher the regex looks correct, so I'm completely stumped here.  Could you try it and tell me if it works for you?
Assignee

Comment 14

12 years ago
This patch addresses Alice's comments.  With her help, I have the one line profile directory capture working again.  Tested on Windows and Mac and Linux.
Attachment #303639 - Attachment is obsolete: true
Attachment #306553 - Flags: review?(anodelman)
Flags: tracking1.9+ → blocking1.9+
Priority: -- → P1
Comment on attachment 306553 [details] [diff] [review]
patch with changes...

This looks a lot better to me.  Thanks for sticking with it!
Attachment #306553 - Flags: review?(anodelman) → review+
Assignee

Comment 16

11 years ago
(In reply to comment #15)
> (From update of attachment 306553 [details] [diff] [review])
> This looks a lot better to me.  Thanks for sticking with it!
> 
Thank you for all your help with it. Patch checked in --> FIXED

Sincerely,
Sed-Expert-In-Training
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Mass moving Minotaur bugs to Testing : Minotaur. Filter on MinotaurMassMove to ignore.
Component: Testing → Minotaur
Flags: blocking1.9+
Product: Core → Testing
QA Contact: testing → minotaur
Target Milestone: mozilla1.9 → ---
Version: Trunk → unspecified

Updated

Last year
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.