Favourites losing the MySQL Host and Password details

[GoogleCodeExporter]

Steps to reproduce

1. create new Favourite using SSH config (may not be tied to this type of 
config however)
2. enter all details
3. connect, then disconntect and try to access favourite again

Expected to have all fields pre-filled with pre-enetered content, instead i see 
most fields with content, except MySQL Host and Password (and sometimes 1 or 
the other)

Using Build 3614

Was working perflectly well before today (ran a daily update this morning), and 
usually update every few days

Original issue reported on code.google.com by da...@temperedvision.com on 3 May 2012 at 12:18

[GoogleCodeExporter]

Verified in r3636.

Additional bug:
* The selected favorite item color is black instead of white.

Original comment by schlabbe...@gmail.com on 8 May 2012 at 8:40

• Changed state: Accepted
• Added labels: Priority-High, Type-Defect, Usability

[GoogleCodeExporter]

Has there been any progress of this issue (ie any indication of release)? As it 
does tend to cause me some considerable trouble on a daily basis at present. :(

Thanks

Original comment by da...@temperedvision.com on 22 May 2012 at 10:45

[GoogleCodeExporter]

Hi David,

We've made a few changes to the connection view in a few revisions up to r3672. 
 I'm not able to reproduce this exact issue though; could you see if it's still 
occurring for you now?

If it is, any consistently reproducible steps would be appreciated :)  For 
example, do you just go to the menu at the bottom and add a new favourite, 
change it to SSH, add the details, and then connect?  Or do you add some of the 
details first, then switch, etc?

Original comment by rowanb@gmail.com on 28 May 2012 at 1:02

• Changed state: WaitingOnUser

[GoogleCodeExporter]

I was unable to reproduce this either, so hopefully it's now fixed.

Oh, and the selected outline view styling issue was addressed in r3662.

Original comment by stuart02 on 28 May 2012 at 7:12

[GoogleCodeExporter]

Issue 1359 has been merged into this issue.

Original comment by schlabbe...@gmail.com on 29 May 2012 at 8:08

[GoogleCodeExporter]

David, Derek:

Derek's mention of the SSH key field made me able to reproduce this; choosing a 
SSL/SSH key would deselect the current favourite, ending editing and resulting 
in an unsaved set of connection details.  This has been fixed in r3674; r3670 
may also have contributed, as until then changes in type could also cause the 
favourite to be deselected.

So please both give the very latest nightly a go, and see if that improves 
matters.

Thanks for your patience :)

Original comment by rowanb@gmail.com on 29 May 2012 at 11:30

[GoogleCodeExporter]

Hi Rownan,

Im afraid the changes dont appear to have any effect with my updated version 
using a pre-existing favourite :(

I've taken a couple of screenshots showing the state (after filling in the 
hostname/password fields), and then immediately after when i try and load the 
favourite again in another tab.

Is this problem potentially one that lead to some kind of corruption that the 
new change is unable to correct?

Thanks,

David

Original comment by da...@temperedvision.com on 31 May 2012 at 2:58

Attachments:

• 2012-05-31_15-47-58.png
• 2012-05-31_15-50-07.png

[GoogleCodeExporter]

Thanks for the extra info David - sorry about this...

While it could in theory be possible for passwords in the keychain to become 
corrupted enough that we then can't work further with them without 
intervention, I just can't see the hostname suffering from the same issue.  But 
is it always the same particular favourites?  (I still can't see this with my 
favourites or newly created favourites)

Your screenshot does show the item still selected on the left, so it's 
definitely not a deselection issue.

Were there any other steps between the two screenshots, or was it just connect 
/ open new tab / see data loss?

It would also be very useful if you could open up 
/Applications/Utilities/Console.app and see if the "All Messages" list contains 
any text for Sequel Pro...

Original comment by rowanb@gmail.com on 2 Jun 2012 at 11:46

[GoogleCodeExporter]

r3677 does a little bit more cleanup on related code, not that I think it'll 
help this issue...

Original comment by rowanb@gmail.com on 3 Jun 2012 at 7:15

[GoogleCodeExporter]

More news on this little issue. I noticed this morning whilst starting the app, 
that my favourites list appears to have reverted to a previous state (losing 
some new favourites and groups), which led me to believe this is some kind of 
app corruption.

I've since completely uninstalled the app, including all related plists etc,  
reinstalled r3676 and added in some new favourities and so far its all looking 
good (restarting the app doest appear to lose favourite info etc).

Not sure why this was the case, but a complete removal does seemed to have 
fixed the error (so possibly related to a corruption after one of the upgrades 
that the app couldnt detect/correct).

But thanks for all the help!

Original comment by da...@temperedvision.com on 3 Jun 2012 at 7:29

[GoogleCodeExporter]

David,

Thanks for the update - that's very interesting, and a little scary :)  Could 
you do one last thing - could you open up /Applications/Utilities/Console.app, 
and filter by Sequel Pro in the top right?  That may give some informative 
error messages...

Original comment by rowanb@gmail.com on 3 Jun 2012 at 7:36

[GoogleCodeExporter]

No Problem. I've attached a report with data since the 28th, giving a few days 
info. From what I can see, there are a couple of items that could be a cause 
for concern, especially the first record and the 2 debug notices.

Original comment by da...@temperedvision.com on 4 Jun 2012 at 12:06

[GoogleCodeExporter]

Actually, the problem did resurface, and I've traced it back to the 
Favourites.plist file in ~/Application Support/Sequel Pro/Data/

When restarting Sequel Pro after a restart, the file was replaced with an empty 
version (I had to restore the original from last night using Time Machine).

Could there be some sort of permissions checking problem on starting the app? 
or could it possibly be related to the Lion 'save state' feature that affects 
restarting?

I've checked perms on the file itself and they appear fine (644, and 755 on 
parent folder).

Original comment by da...@temperedvision.com on 4 Jun 2012 at 12:11

[GoogleCodeExporter]

sry, realised I attached the wrong file to the previous reply. log file now 
attached

Original comment by da...@temperedvision.com on 4 Jun 2012 at 12:12

Attachments:

• console.log

[GoogleCodeExporter]

I tried posting the following report last week but couldn't so I'm adding it 
now:

I'm afraid the latest nightly (3675) does not fully resolve the issue for me 
either. I re-entered the information missing in my existing favourites. Most of 
the information was retained but I had to delete the keychain entry for one of 
them before it would "stick". However, just when I thought the problem was 
resolved, I discovered that at least one of my other favourites had lost its 
settings again. :(

There's nothing particularly informative in Console.log (just a couple of 
messages related to the upgrade to the latest nightly, 3680).

Original comment by fong.de...@gmail.com on 4 Jun 2012 at 3:02

[GoogleCodeExporter]

Derek, David,

I'm afraid I'm still can't reproduce this, despite creating a whole load of new 
favourites with what sounds like a similar setup to Derek's: all details seem 
to be preserved correctly.

As you mention, the console logs don't look unusual: the lines about being 
unable to backup the version are a concern, but we think that was fixed the day 
after in r3673.

There's two possibilities here:
 - The live edit capabilities are resulting in a change to the UI (or connection controller) as a result of another action are cascading through and being saved automatically to the last selected favourite.
 - During the favourites save, some details are being lost on unrelated favourites: eg favourite 5 is edited, favourite 3 loses its host details.

The former seems much more likely, but I've gone through code which affects the 
host - as that seems to be the item most mentioned - and can't find an obvious 
culprit.  (The host being lost would cause a password loss at the same time, as 
it'd still be in the Keychain but no longer locatable.)

(The code reviews and testing have a resulted in the cleanup of a few edge 
cases resulting in lost passwords - r3681, r3682 - and one which could also 
change the default name in r3683 - but I don't think they'd have affected 
established SSH host details).

Without a reproducible test case so we can pin this down, we're currently a bit 
stuck.  However, frustrating as this is, there's a bigger change coming up: 
Issue #1339 is tracking a change so that favourite changes are no longer saved 
at once; instead, favourites remain editable on the connection screen, but 
there's a button to save any changes.  This should fix this issue, as if it is 
some action clearing the host (possibly *after* connection), that change will 
no longer automatically be saved...

Original comment by rowanb@gmail.com on 5 Jun 2012 at 1:32

• Changed state: Accepted

[GoogleCodeExporter]

Rowan,

AFAIK, the SSH host key setting is now always respected, it seems to only be 
the hostname and/or the password field that gets lost.

And just this morning, with build 3681, I noticed something extremely bizarre.

Cycling through my favourites (to see which ones had missing info in them), I 
noticed a couple of favourites whose hidden passwords (dots) were longer than 
they should have been. For example, one of my dev servers has a three-letter 
password, but Sequel Pro displayed something like 8 or 9 dots instead. I found 
another favourite with the same problem, so I opened up the Keychain entry and 
found the password was something completely different than what it should have 
been. In fact, I have two keychain entries for the same host, one which was 
last modified on May 29 and the newer one from a few minutes ago when I 
corrected the password for that favourite.

I have 20 favourites, some which have "@" in their names. Would anything like 
that be problematic? And where would the random password have come from? (FWIW, 
the password looks familiar—I wonder if it's a password that should have been 
assigned to another favourite.)

Original comment by fong.de...@gmail.com on 5 Jun 2012 at 2:28

[GoogleCodeExporter]

Derek,

You're exactly right - the password would have been copied from another 
favourite.  I broke this last night in r3681 in a slightly overenthusiastic fix 
for passwords being lost for certain types of connection type, and fixed it 
this morning in r1382 (all UK time).  Switching from a favourite to another 
favourite with a different type would have accidentally saved the password to 
the wrong one - sorry :(

"@" in a favourite name shouldn't cause any issues.

Original comment by rowanb@gmail.com on 5 Jun 2012 at 2:32

[GoogleCodeExporter]

Rowan, yup the latest nightly fixes the password issue I reported in comment 
#17. =)

Unfortunately, my last statement about SSH key settings being retained is not 
accurate. I'm noticing missing SSH keys in the favourites I fixed late last 
week. :(

Original comment by fong.de...@gmail.com on 5 Jun 2012 at 3:30

[GoogleCodeExporter]

Just to make sure this is not an issue:
The log from David shows that TextExpander and SIMBL is used.
Both COULD hook a text input in a way that conflicts with Sequel Pro.

Are you using any similar system extensions?

Original comment by schlabbe...@gmail.com on 5 Jun 2012 at 7:19

[GoogleCodeExporter]

No such extensions here, AFAIK.

Original comment by fong.de...@gmail.com on 5 Jun 2012 at 7:21

[GoogleCodeExporter]

Is it possible Sequel Pro is using older versions of favourites and/or prefs 
files? I have just experienced the same issue as David in comment #10. It 
sounds a bit nutty, but I think that's what's happening here.

Yesterday, I had a couple of favourites that had lost their connection details, 
so I filled them in, and re-launched Sequel Pro just to be sure they would 
stick (which they did). I worked this way all day without further incident or 
data loss (quitting and re-launching Sequel Pro throughout the day). I thought 
this bug had finally been resolved.

This morning, I launch Sequel Pro (build 3685) and discover that ALL of my 
favourites are now missing their settings for the SSH key (and in some cases, 
the MySQL DB password), but the kicker is that one of the favourites I had 
deleted yesterday is now back in my list.

Original comment by fong.de...@gmail.com on 8 Jun 2012 at 2:14

[GoogleCodeExporter]

Derek,

That's... odd.  There was a problem with a logic error in the backup step of 
saving changes, resulting in the save being aborted, but Stuart should have 
fixed that over a week ago.  Could you check Console.app, see if there's 
anything new and pertinent mentioned in there?

(More questions: have you launched a previous version of Sequel Pro?  Have you 
used the groups functionality at all to organise your favourites, and if so, 
were they preserved or did it look like it reverted to a version from several 
weeks ago?)

Original comment by rowanb@gmail.com on 10 Jun 2012 at 9:03

[GoogleCodeExporter]

Rowan, very odd, but I was able to reproduce that again. Again, nothing weird 
shows up in Console aside from the usual messages when updating Sequel Pro to a 
newer build.

This morning, I was prompted to update to the latest build (3687). Before I did 
so, I deleted one of my favourites (the one that keeps coming back). Quit, 
re-launched Sequel Pro (without updating) and confirmed that the favourite was 
gone. Ran the update, re-launched, and lo and behold, the deleted favourite was 
back!

I haven't launched a previous version of Sequel Pro, no groups functionality in 
use. It doesn't seem to have reverted to a version from several weeks ago.

Original comment by fong.de...@gmail.com on 11 Jun 2012 at 6:09

[GoogleCodeExporter]

I just had the same error come back again. Completely replaced the favourites 
menu a few days ago, been working absolutely fine, used it earlier today, fine. 
Used it just now, reverted to old version.

... something very weird is going on here. Its like its copying an old version 
back from time machine.

Original comment by da...@temperedvision.com on 13 Jun 2012 at 7:53

[GoogleCodeExporter]

Something is definitely causing Sequel Pro to revert to an earlier version of 
Favourites.

Over the last few days (perhaps since last week?), Sequel Pro's been running 
fine. It hasn't been forgetting my favourites' settings (AFAIK) and no other 
issues have cropped up... until this morning.

I was prompted to upgrade to the latest nightly (3690) and as Sequel Pro was 
updating itself, I noticed that a favourite I had deleted last week was back 
AND a favourite I had subsequently created was no longer in my list. Since 
Sequel Pro has re-launched, I am now noticing several favourites which have 
lost some settings... similar to the situation I was in last week when I had 
fixed all of my favourites.

Original comment by fong.de...@gmail.com on 19 Jun 2012 at 12:56

[GoogleCodeExporter]

Hi guys,

Sorry for the long delay in tracking this down.  I finally pinned down a 
reproducible test case involving a certain series of edits, connections, and 
window closes, after which the favourites would be lost *on quit*.  I tracked 
this down to the pref save routine called on quit, which renamed the old 
Favorites.plist to a UUID-like filename (for backup), converted the favourites 
data to a saveable format, and... died.

The application appears to exit cleanly; I don't know why it would suddenly 
stop part-way through a function, in the middle of logic.

I've reordered the save logic to make it much more safe; first the conversion 
processes are handled, then the file is backed up, new file written, and backup 
deleted or restored as appropriate.  My test cases now all work so I'm hopeful 
this is fixed at last.  Upgrade to r3695, keep an eye on your favorites over 
the next few days, and let me know...

Original comment by rowanb@gmail.com on 22 Jun 2012 at 1:51

• Changed state: WaitingOnUser

[GoogleCodeExporter]

Thanks for this Rownan, so glad you were able to track down the problematic 
functionality.

I'll test this over the next few days and report back any probelms (fingers 
crossed there wont be any!)

Original comment by da...@temperedvision.com on 22 Jun 2012 at 10:25

[GoogleCodeExporter]

Phill on IRC reported he still saw a regression with r3695.  Thinking about it, 
the on-quit pref save routine triggered a background thread, which may have 
been killed on exit of the main thread - which would explain exit part-way 
through a function.  In r3696 I've altered the on-quit pref save routine to 
block the main thread until done, which should stop it from being killed, and 
improved logging a bit more for better console.app messages if it does fail for 
other reasons.

Original comment by rowanb@gmail.com on 23 Jun 2012 at 12:13

[GoogleCodeExporter]

Issue 1382 has been merged into this issue.

Original comment by rowanb@gmail.com on 25 Jun 2012 at 7:08

[GoogleCodeExporter]

FYI I have not had a recurrence of this issue so far, although I have not been 
adding/deleting favourites as much lately.

Original comment by fong.de...@gmail.com on 3 Jul 2012 at 8:30

[GoogleCodeExporter]

No recurrence of the problem here either, so it looks like we can put a big 
tick through this one :)

Original comment by da...@temperedvision.com on 3 Jul 2012 at 10:44

[GoogleCodeExporter]

Original comment by stuart02 on 7 Jul 2012 at 11:31

• Changed state: Verified