Should be a progress bar to indicate it being in progress while restoring bookmark from JSON




2 years ago
10 months ago


(Reporter: masayuki, Unassigned)


(4 keywords)

dataloss, feature, ux-implementation-level, ux-userfeedback

Firefox Tracking Flags

(Not tracked)


Due to synced with old Nightly in VM, my bookmark order was broken. Therefore, I tried to restore bookmarks from bookmarkbackups in the profile folder via Library.

At this time, looks like the UI hangs and took very long time but there is no UI which indicates how much jobs are completed and still in progress normally or not.

So, I'd love a dialog which has a progress bar and brief message describing which bookmark item is in progress if there were.

Such UI must make users free from stress and might help to investigate bug 950533.
or at least some confirmation dialog after completing bookmark importing/exporting task
Severity: enhancement → normal
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox55: --- → affected
status-firefox-esr45: --- → affected
status-firefox-esr52: --- → affected
Keywords: dataloss, ux-implementation-level, ux-userfeedback
See Also: → bug 1320537, bug 1320538
There's also those other bugs asking for a notification at the end.

Off-hand I don't think we're likely to have time to work on a good progress UI, plus tracking progress is really hard, because it's a mixture of number of bookmarks, global system I/O, fsyncs, UI notifications... It would end up being the usual "random" progress bar that doesn't really give an idea of how long it will take. I hate those progress bars where you reach 95% in 10 minutes and expect it to finish soon, and instead it gets stuck there for 1 hour before proceeding.

I rather think we should spend time on other things:
1. Gijs is working on a new insertTree API that could be used for imports, once available. He said it's largely improving insert times (bug 1344282)
2. We should complete the move to async bookmarks APIs. The current code still uses the synchronous APIs and thus it blocks the main-thread forever (bug 1095426). Using 1) would at the same time improve speed and fix this, but requires refactoring the module a bit to do the insert at once.
3. We should likely add a shutdown blocker when a backup/restore is ongoing, as I suggested in the other 2 bugs.
4. We should rewrite the observers system to not flood the main-thread with thousands of notifications (bug 1340498)

By doing these it's likely we can complete the import in a few seconds, and don't block the main-thread in most cases. That makes pointless any kind of additional UI.

Now, the problem I have is that there's no Places team, so there's barely no resources to work on most of these issues. While I try to do some of this work in spare time between other projects, it's unlikely I can do all of it. Luckily some of the work (insertTree) is happening because of other teams needing it, so we can still slowly move towards our goal.
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
status-firefox51: affected → ---
status-firefox52: wontfix → ---
status-firefox53: affected → ---
status-firefox54: affected → ---
status-firefox55: affected → ---
status-firefox-esr45: affected → ---
status-firefox-esr52: affected → ---
Keywords: feature


2 years ago
Priority: -- → P5


10 months ago
Severity: normal → enhancement


10 months ago
Blocks: 1430401


10 months ago
Duplicate of this bug: 1431319
Lets not have multiple bugs for slightly different things unless we know we're actually going to implement them. Consolidating into bug 1432738.
Last Resolved: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1432738
You need to log in before you can comment on or make changes to this bug.