Open Bug 1517130 Opened 2 years ago Updated 10 months ago

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

Categories

(Toolkit :: Places, defect, P3)

64 Branch
defect

Tracking

()

People

(Reporter: msvc, Unassigned)

References

(Depends on 1 open bug)

Details

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).
I'll let lina chime in here, to evaluate what is strictly necessary for Sync.
Flags: needinfo?(lina)
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.
Status: UNCONFIRMED → NEW
Component: Bookmarks & History → Places
Ever confirmed: true
Flags: needinfo?(lina)
Product: Firefox → Toolkit
Summary: Library (Bookmarks Manager) - Moving bookmarks alters modification-time → Moving a bookmark updates its last modified time as well as its parent's
Flags: needinfo?(lina)
Priority: -- → P3

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.)

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.

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

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

Flags: needinfo?(mak77)

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.

Depends on: 1433177
Flags: needinfo?(mak77)
Flags: needinfo?(lina)

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.)

You need to log in before you can comment on or make changes to this bug.