1603900 - System idle doesn't run with a video desktop background

Status: NEW

(Core :: Widget: Gtk, defect, P2)

Description

[RagglenLove]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Expected results:

Unlike in previous versions of Firefox, bookmarkbackups files not being created daily as they should in the bookmarkbackups folder.

My last bookmarkbackups file was dated 2019-10-16 (Oct 16, 2019).

Comment 1

[Hani Yacoub, Desktop QA]

Setting this bug to "Toolkit: places" component.

Comment 2

[Marco Bonardo [:mak]]

backups are not created "daily", they are only if the bookmarks changed. If you changed your bookmarks from 2019-10-16, then it's likely there's a data coherence problem in the database.
Places try running Places Database Integrity Check from about:support and post the results here.
If you go to the Library window (Show all bookmarks) and try do to a manual backup from the menu there, does it work? If it doesn't work, do you see any error printed in the Browser Console?

Comment 3

[RagglenLove]

backups are not created "daily", they are only if the bookmarks changed. If you changed your bookmarks from 2019-10-16, then it's likely there's a data coherence problem in the database.

Yes, from Oct to Dec, my bookmarks have changed, I've removed old bookmarks and added new bookmarks.

Places try running Places Database Integrity Check from about:support and post the results here.

Here's the results:

Task: checkIntegrity

• The places.sqlite database is sane
• The favicons.sqlite database is sane

Task: invalidateCaches

• The caches have been invalidated

Task: checkCoherence

• The database is coherent

Task: expire

• Database cleaned up

Task: originFrecencyStats

• Recalculated origin frecency stats

Task: vacuum

• Initial database size is 1664KiB
• The database has been vacuumed
• Final database size is 5120KiB

Task: stats

• Places.sqlite size is 5120KiB
• Favicons.sqlite size is 9504KiB
• pragma_user_version is 53
• pragma_page_size is 32768
• pragma_cache_size is -2048
• pragma_journal_mode is wal
• pragma_synchronous is 1
• History can store a maximum of 65921 unique pages
• Table moz_origins has 455 records
• Table moz_places has 1429 records
• Table moz_historyvisits has 0 records
• Table moz_inputhistory has 0 records
• Table moz_bookmarks has 1486 records
• Table moz_bookmarks_deleted has 0 records
• Table moz_keywords has 0 records
• Table sqlite_sequence has 0 records
• Table moz_anno_attributes has 0 records
• Table moz_annos has 0 records
• Table moz_items_annos has 0 records
• Table moz_meta has 4 records
• Table sqlite_stat1 has 12 records
• Index sqlite_autoindex_moz_origins_1
• Index sqlite_autoindex_moz_inputhistory_1
• Index sqlite_autoindex_moz_bookmarks_deleted_1
• Index sqlite_autoindex_moz_keywords_1
• Index sqlite_autoindex_moz_anno_attributes_1
• Index moz_places_url_hashindex
• Index moz_places_hostindex
• Index moz_places_visitcount
• Index moz_places_frecencyindex
• Index moz_places_lastvisitdateindex
• Index moz_places_guid_uniqueindex
• Index moz_places_originidindex
• Index moz_historyvisits_placedateindex
• Index moz_historyvisits_fromindex
• Index moz_historyvisits_dateindex
• Index moz_bookmarks_itemindex
• Index moz_bookmarks_parentindex
• Index moz_bookmarks_itemlastmodifiedindex
• Index moz_bookmarks_dateaddedindex
• Index moz_bookmarks_guid_uniqueindex
• Index moz_keywords_placepostdata_uniqueindex
• Index moz_annos_placeattributeindex
• Index moz_items_annos_itemattributeindex

Task: _refreshUI

If you go to the Library window (Show all bookmarks) and try do to a manual backup from the menu there, does it work? If it doesn't work, do you see any error printed in the Browser Console?

Yes, it does work.

I've also set "browser.bookmarks.max_backups" to "1".

Comment 4

[Marco Bonardo [:mak]]

(In reply to RagglenLove from comment #3)

I've also set "browser.bookmarks.max_backups" to "1".

Why?
Do you mean you just did it, or you flipped that setting in the past?
If you did in the past, that may be part of the problem, maybe the code has a bug for which it won't create a backup if the pref is set to 1.
Could you please try increasing it (or resetting it) and see if the problem disappears? That would be a great hint for us to find the problem.

Comment 5

[RagglenLove]

(In reply to Marco Bonardo [:mak] from comment #4)

(In reply to RagglenLove from comment #3)

I've also set "browser.bookmarks.max_backups" to "1".

Why?
Do you mean you just did it, or you flipped that setting in the past?
If you did in the past, that may be part of the problem, maybe the code has a bug for which it won't create a backup if the pref is set to 1.
Could you please try increasing it (or resetting it) and see if the problem disappears? That would be a great hint for us to find the problem.

It's an old setting that I always did to reduce memory consumption, and as I said, setting this to "1" didn't have a problem in previous versions of Firefox, in the past, whenever a new backup is created, it would overwrite the existing backup in the folder.

Comment 6

[RagglenLove]

< Could you please try increasing it (or resetting it) and see if the problem disappears? That would be a great hint for us to find the problem.

That fixed the issue, the moment I reset "browser.bookmarks.max_backups" to default, which is "15", the bookmarkbackups file updated itself to 019-12-19. But this is still a bug though, because as I said, in previous versions of Firefox, setting "browser.bookmarks.max_backups" to "1" didn't prevent the creation of new bookmarkbackups files, it would only overwrite the previous file.

Comment 7

[Marco Bonardo [:mak]]

The numeber of backups should have no influence on memory consumption, at a maximum it will save a few KiBs of disk space, nothing major. That pref exists mostly for people having a profile in a quota limited disk, or willing to increase the number of backups.

You are right that setting it to 1 should always keep only 1 backup, and update it, it sounds like there's a bug there.

Thanks for reporting back!

Comment 8

[RagglenLove]

(In reply to Marco Bonardo [:mak] from comment #7)

The numeber of backups should have no influence on memory consumption, at a maximum it will save a few KiBs of disk space, nothing major. That pref exists mostly for people having a profile in a quota limited disk, or willing to increase the number of backups.

You are right that setting it to 1 should always keep only 1 backup, and update it, it sounds like there's a bug there.

Thanks for reporting back!

Thanks for updating the bug report. Hopefully, this gets fixed. Merry Christmas!

Comment 9

[RagglenLove]

(In reply to Marco Bonardo [:mak] (Away 23 Dec - 6 Jan) from comment #7)

The numeber of backups should have no influence on memory consumption, at a maximum it will save a few KiBs of disk space, nothing major. That pref exists mostly for people having a profile in a quota limited disk, or willing to increase the number of backups.

You are right that setting it to 1 should always keep only 1 backup, and update it, it sounds like there's a bug there.

Thanks for reporting back!

There seems to be a bug in browser.bookmarks.max_backups itself. From Dec 19 to 21, I added new bookmarks, but still, the bookmarkbackups folder doesn't reflect these changes as the .jsonlz4 file is still dated Dec 21.

Comment 10

[RagglenLove]

(In reply to RagglenLove from comment #9)

(In reply to Marco Bonardo [:mak] (Away 23 Dec - 6 Jan) from comment #7)

The numeber of backups should have no influence on memory consumption, at a maximum it will save a few KiBs of disk space, nothing major. That pref exists mostly for people having a profile in a quota limited disk, or willing to increase the number of backups.

You are right that setting it to 1 should always keep only 1 backup, and update it, it sounds like there's a bug there.

Thanks for reporting back!

There seems to be a bug in browser.bookmarks.max_backups itself. From Dec 19 to 21, I added new bookmarks, but still, the bookmarkbackups folder doesn't reflect these changes as the .jsonlz4 file is still dated Dec 21.

correction: Dec 19

Comment 11

[Marco Bonardo [:mak]]

it may take 2 to 3 days, it uses idle time, if the browser is not idle it can't act, but it will force a shorter idle after a couple days.

Comment 12

[RagglenLove]

(In reply to Marco Bonardo [:mak] (Away 23 Dec - 6 Jan) from comment #11)

it may take 2 to 3 days, it uses idle time, if the browser is not idle it can't act, but it will force a shorter idle after a couple days.

Thanks for the heads up on that one.
Anyway, I'll be observing this from now til Dec 31 and to see if the .jsonlz4 file is still dated Dec 19.

Comment 13

[RagglenLove]

I've returned your previous summary, and I will update this after New Years if the .jsonlz4 file is still dated Dec 19.

Comment 14

[RagglenLove]

I've observed my bookmarkbackups folder and the .jsonlz4 file is still dated Dec 19, 2019.

Comment 15

[Mark Banner (:standard8)]

(In reply to RagglenLove from comment #14)

I've observed my bookmarkbackups folder and the .jsonlz4 file is still dated Dec 19, 2019.

Have you tried leaving Firefox running, and not doing anything on the system for say an hour?

Also, if you go back into about:support and look for the "Important Modified Preferences" section, what is the value of idle.lastDailyNotification in that list?

Comment 16

[RagglenLove]

Also, if you go back into about:support and look for the "Important Modified Preferences" section, what is the value of idle.lastDailyNotification in that list?

Here it is:
idle.lastDailyNotification 1571204182

Have you tried leaving Firefox running, and not doing anything on the system for say an hour?

I'll give it try thanks, I'll report back in an hour.

Comment 17

[RagglenLove]

Have you tried leaving Firefox running, and not doing anything on the system for say an hour?

I've tried it and no change to bookmarkbackups.

Comment 18

[Mark Banner (:standard8)]

(In reply to RagglenLove from comment #16)

Here it is:
idle.lastDailyNotification 1571204182

Thanks, that time equates to Wed Oct 16 2019 06:36:22 GMT+0100 - so it has been a few months since Firefox has scheduled an idle routine.

My value for that is 1578044305 which is Fri Jan 03 2020 09:38:25 GMT+0000 and equates to this morning my time which is probably about right.

From reading the code, it looks like daily idle will normally be triggered after it has seen the system idle for 3 minutes, or after 1 minute if it has been a long time since the last daily idle.

From the looks of it, we're using xscreensaver on Linux to determine how long the system has been idle. If xscreensaver isn't found, then I think we fallback to using the time since the last detect input event.

What you could try is getting a log of the idle service, and see if that tells us what is wrong. You need to start Firefox with a couple of environment variables set, something like:

MOZ_LOG="timestamp,idleService:5" MOZ_LOG_FILE="/home/me/mylog.txt" firefox

There's a bit more information here if you need it: https://developer.mozilla.org/docs/Mozilla/Developer_guide/Gecko_Logging

Comment 19

[Mark Banner (:standard8)]

Just to confirm, your browser.bookmarks.max_backups preference is now back at the default of 10?

Also when you're running the idle log, try leaving it for about 5 minutes. Hopefully that won't generate too much logging.

Comment 20

[RagglenLove]

Attachment: mylog.txt.moz_log

Comment 21

[RagglenLove]

Okay, I've left my computer alone for more than five minutes while it does it's idle log. I've attached the log file to the bug report.

Yes, browser.bookmarks.max_backups is set to 15, the default setting for my Firefox.

Comment 22

[Mark Banner (:standard8)]

Thank you for the logs, that is very interesting.

For the period of the logs that looks like the steady-state, Firefox is setting a timer to check for idle every 20 seconds. The log says that the last interaction is always within a few milliseconds of the timer.

I can also see that it appears that it is getting the idle time information from xscreensaver (I'm assuming you're on Linux as per comment 0).

Hence, xscreensaver is thinking that your system is never idle, and so Firefox isn't kicking in the idle observer.

Have you checked to see if you've got processes running actively in the background that could cause your system not to idle? Does your screensaver kick in when you expect it to?

Comment 23

[RagglenLove]

I'm using a video as a desktop wallpaper. Here are the instructions that I'm using: https://ubuntuforums.org/showthread.php?t=2424486&page=2&p=13879033#post13879033

With my video wallpaper, my system doesn't sleep.

Comment 24

[Mark Banner (:standard8)]

Thank you for confirming that. You should find that if you disable that at least temporarily then Firefox should save the bookmarks file.

Unfortunately I'm not sure what we can do about it - we purposely wait for the system to be idle so that we're not doing these tasks whilst the user is active. I'll ask a few people later today.

Comment 25

[RagglenLove]

(In reply to Mark Banner (:standard8) from comment #24)

Thank you for confirming that. You should find that if you disable that at least temporarily then Firefox should save the bookmarks file.

Unfortunately I'm not sure what we can do about it - we purposely wait for the system to be idle so that we're not doing these tasks whilst the user is active. I'll ask a few people later today.

Thanks, at the same time, I'll ask around the Ubuntu Forums about configuring my bash script to allow my system to become idle while playing the looping video as my desktop wallpaper.

Comment 26

[RagglenLove]

https://ubuntuforums.org/showthread.php?t=2434521

It's fixed now.

bash -c "sleep 1; mpv -loop-file=inf --no-stop-screensaver --no-audio --osc=no --cursor-autohide=no --wid=$(wmctrl -l|awk '/pcmanfm/ {print $1}') /path/to/video"

By adding --no-stop-screensaver to my bash script, my video wallpaper allows my system to become idle now, and bookmarkbackups created a new jsonlz4 file dated 2020-01-07.

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 28

[Mark Banner (:standard8)]

Thank you for the updates. This would seem like we need to update the Firefox idle service mechanism so that if the system is seen as permanently busy, then we have some sort of fallback to allow these idle-daily cleanups to occur (there's more than just the saving backups).

Comment 29

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.