690954 - "Most Visited" smart folder gets reordered incorrectly

Status: RESOLVED INVALID

(Firefox :: Sync, defect)

Description

[jorge alves]

This started happening recently on my two nightly installs.

I have the bookmarks toolbar with "Most Visited" as the first available item but every once in a while it jumps to the last position. I wasn't able to reproduce it on-demand.

My sync account also covers a 3.6 namoroka, a 3.6 beta and at least two 6.0.2 Firefox builds but these are used rarely (but always updated when I do).

It could be something else causing this problem but Sync would be a good first guess.

Comment 1

[Richard Newman [:rnewman]]

(In reply to jorge alves from comment #0)

> It could be something else causing this problem but Sync would be a good
> first guess.

Which version of Sync do you have installed on the 3.6 profiles?

We've had very, very few bookmark issues reported since Bug 621584 was addressed; only one in recent memory.

We eagerly anticipate no longer supporting the Sync add-on for 3.6; it hasn't been updated since around when Firefox 4 was released.

Comment 2

[jorge alves]

At the moment I only have my namoroka install available and Sync's version is 1.7.

Just tried moving bookmarks around (including Most Visited) and synching on both ends multiple times and everything seems to work fine.

I looked around about:config for logging options but there are a few. What would you recommend me do to better assess the issue?

Comment 3

[Richard Newman [:rnewman]]

(In reply to jorge alves from comment #2)

> I looked around about:config for logging options but there are a few. What
> would you recommend me do to better assess the issue?

Setting

  services.sync.log.logger.engine.bookmarks

to "Trace" (capital "T") and restarting the browser will make your bookmark logs very verbose (and personally identifiable).

If you capture the last few hundred lines after you notice something reordered, that will help.

Comment 4

[jorge alves]

Attachment: log file from when the problem occurs

I did have to enable services.sync.log.appender.file.logOnSuccess otherwise nothing was being logged.

For privacy reasons, I'd prefer not to attach the file here (all my bookmarks are in there) so this is a reduced version. I won't mind sending in the whole file by email to a @mozilla account.

Note: I was only using nightlies this time (both current).

Comment 5

[Richard Newman [:rnewman]]

(In reply to jorge alves from comment #4)

> For privacy reasons, I'd prefer not to attach the file here (all my
> bookmarks are in there) so this is a reduced version. I won't mind sending
> in the whole file by email to a @mozilla account.

Please send to rnewman@.

Comment 6

[Tracy Walker [:tracy]]

mass change of sync error bugs filed during outage.

Comment 7

[jorge alves]

(In reply to Richard Newman [:rnewman] from comment #5)
> (In reply to jorge alves from comment #4)
> 
> > For privacy reasons, I'd prefer not to attach the file here (all my
> > bookmarks are in there) so this is a reduced version. I won't mind sending
> > in the whole file by email to a @mozilla account.
> 
> Please send to rnewman@.

Unfortunately I don't have it anymore but maybe they weren't important? They were repeating the two lines I mention in the attached log where I say "a bunch of lines with the bookmarks, like the following:". Nothing else.

Trying to reproduce it today I found the following:

i) Manually creating the "Most Visited" bookmark with the URI "place:queryType=0&sort=8&maxResults=10" creates a broken bookmark. Only after restarting the browser it starts to work.

ii) I seem to have an "immortal" "Most Visited" in one of the clients. I removed it in one client and it was synched correctly but, upon restarting the client where I deleted it, it comes back in position 0. In the other client it was gone for good.

iii) This "immortal" bookmark is the one that jumps to the end of the list any time I make a change to the bookmarks toolbar in the other client. Maybe before the delete I had one of these in both clients.

Note: these tests were done with today's nightly on both ends, nothing else.

Comment 8

[Tracy Walker [:tracy]]

Servers were repaired. marking as FIXED

reporter, please reopen if this occurs with current nightly builds. And always provide logs as per instructions at https://philikon.wordpress.com/2011/06/13/how-to-file-a-good-sync-bug/

Comment 9

[jorge alves]

Just FYI, this issue was solved but it wasn't a sync problem.

My profile had the following setting set to "2":
browser.places.smartBookmarksVersion

This should be the proper value if we don't want firefox to regenerate the default smart bookmarks on restart, therefore I didn't investigate the issue further at the time of reporting. However, this was defined as a "string". Resetting it caused the bookmarks to reappear again but this time the setting became an "integer". Afterwards it stopped generating new bookmarks.

I don't know what caused it to be a string in the first place (I don't recall messing with it), but the bookmarks were being recreated on every restart and confusing Sync.

All is well on my end now.

Comment 10

[Richard Newman [:rnewman]]

Thanks for letting us know, Jorge.

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I quickly checked the code and all the setters are correctly using setIntPref, so I can't tell what could have set a string there.

Comment 12

[Richard Newman [:rnewman]]

mak: it could have been a pref sync bug in Sync <= 1.7; there were 3.6* apps connected to the account.

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Ah, interesting!