1517130 - Moving a bookmark updates its last modified time as well as its parent's

Status: NEW

(Toolkit :: Places, defect, P3)

Description

[msvc]

Reproduce: Move bookmarks around/rearrange them within the favorites-library.
(Drag & drop or 'Organise -> Move' or address-bar star-icon.)

Since Firefox v53 (https://bugzilla.mozilla.org/show_bug.cgi?id=1258127) moving bookmarks directly from the star-icon or within library to another directory/folder changes the 'last modified' date/time of the bookmark itself (and not just the folders timestamp).

The 'moz_bookmarks.syncChangeCounter' value is already updated when the bookmark is moved/changed its location, so why is it necessary to set its timestamp too?

This way one can't sort/rearrange any bookmarks without messing up their original modification-date. With earlier Firefox ESR versions (v52) this wasn't a problem.
I'm never using (or used) the sync-function at all, so is it possible to restore the original 'file manager' moving-behaviour regarding item/entry-timestamps, when there's no Firefox account/sync available (or in general).

Comment 1

[Marco Bonardo [:mak]]

I'll let lina chime in here, to evaluate what is strictly necessary for Sync.

Comment 2

[Lina Butler (ex-Mozilla)]

Good catch!

We don't need to bump the bookmark's modified date for new bookmark sync (bug 1433177), since we check the timestamp of the bookmark and its parent to resolve merge conflicts (https://searchfox.org/mozilla-central/rev/a0841a254f67ae6c58a7b03473b6c8a10d928368/toolkit/components/places/SyncedBookmarksMirror.jsm#3471-3474,3669-3674). Unfortunately, we aren't ready to pref that on for everyone yet, though we hope to in the 67 cycle.

Because the old engine applies records one at a time, though, if you make conflicting changes to an item on multiple devices, we might revert a move, and, for good measure, leave the child in multiple parents on the server. So we do need to bump the last modified time of the child and its parent for bookmark sync to work correctly today.

We can _probably_ get away with only bumping last modified for bookmarks that have been synced (`syncStatus = NORMAL`), and leave unsynced bookmarks alone. That might be oddly inconsistent for a couple of releases, but temporary, and only affecting Sync users. Let me think a bit more about that.

Comment 3

[msvc]

So it probably will be resolved in the public release of May 2019? Is there any other workaround, e.g. add-on or browser setting, that can be used to 'non-invasively' sort/rearrange bookmarks in the meantime? (Other than SQLite database-fiddling of course.)

Comment 4

[Lina Butler (ex-Mozilla)]

At the earliest, yes. I don't believe Web Extensions can update a bookmark's last modified time, only its title and URL, so it's not possible for an add-on to work around this behavior.

Comment 5

[msvc]

Still happens with Firefox DE v68.0b11. Will there be any progress in the next release?

Comment 6

[msvc]

What's the current prospect for this issue to get fixed?

Comment 7

[Mark Banner (:standard8)]

Given as Lina said earlier, the new bookmark sync will automatically fix this, I doubt we're going to do specific work on this anytime. Currently, it is hoped that the new sync will be turned on in 70.

Comment 8

[msvc]

Will there be a notice/comment in bug #1433177 when it's going to be fixed/updated in beta or final release of Firefox?
(Current Firefox Nightly v71 doesn't have it, looks like only next year something will be changed.)

Comment 9

[msvc]

It's gotten worse, currently even 'Sort By Name' function changes the timestamps of ALL bookmarks (in sorted directory).
What's the actual issue with restoring the original (more senseful) routine? This is horrendous!

Comment 10

[Marco Bonardo [:mak]]

At the moment changing any detail of the bookmark changes its modified time. That was by design rather than a bug, maybe a wrong design decision, though.

I can understand the frustration here, we could limit that behavior to when either the title, the url, the keyword, or tags change. The other details are secondary to the bookmark lifecycle.

This is still a low priority unfortunately, but we welcome patches.