Freshrss: [Bug] "Mark as read" check is never shown

[lapineige]

Hello FreshRSS team,

since a while (I think version 1.5) the confirmation when "mark as read" is clicked is not shown.
Even if I disable and enable it again.
On desktop it wasn't a problem, but on phone it's super easy to make a mistake and... mark all feed.
Hopefully I have a recent backup, so I didn't loose hundreds of articles.
But it's really an annoying bug.

Even if the check is working, I failed (on a phone again ^^) several times in the past.
So if you could enable a kind of double check, it could be really useful :)
Or even better, a (special ?) log with the list of articles marked, so we can use it in a script to restore everything (with an extension ?).

Thanks :)

[lapineige]

How could I check what's (not) working ?
Is there any log, or any command I could run, to test if the parameters is really activated, and if this activation is taken into account ?

[Alkarex]

I cannot immediately reproduce the problem (tested only in Firefox so far, on desktop and mobile).

How to debug:

• First, check that there is no error in the Web browser's JavaScript console
• All user options are saved in ./data/users/[username]/config.php
  
  
  
  • The relevant option is reading_confirm
  
  
• Then you can check that the option is correctly sent to the Web client. In this case, there is an additional confirm class in some buttons <button class="... confirm ..." ...>
• Finally, via your browser's developer tools, put a breakpoint in main.js in the relevant function, and see that it is called correctly, in this case:

    $('body').on('click', '.confirm', function () {
        var str_confirmation = $(this).attr('data-str-confirm');
        if (!str_confirmation) {
            str_confirmation = i18n.confirmation_default;
        }

        return confirm(str_confirmation);
    });

[lapineige]

First, check that there is no error in the Web browser's JavaScript console

I did it, nothing.

The relevant option is reading_confirm

Ok that's true, so no problem here.

Then you can check that the option is correctly sent to the Web client. In this case, there is an additional confirm class in some buttons

It is here as expected.

Finally, via your browser's developer tools, put a breakpoint in main.js in the relevant function, and see that it is called correctly, in this case:

Hum I didn't think about this, that's clever, thanks :)
Here become the funny stuff: If I set a break point (and run it step by step), it works.
If not, nothing happens.

[Alkarex]

What version of FreshRSS, and which browser / platform?

[lapineige]

1.5 (shipped with yunohost - so on a debian) accessed from Firefox / Kubuntu.

[lapineige]

I just saw that the new CLI can be really handy to make some (automated) backups on a regular base: https://github.com/FreshRSS/FreshRSS/pull/1338

Thanks to this command: ./cli/export-opml-for-user.php --user username > /path/to/file.opml.xml
(question: what's the difference with export-zip ?)
Actually I'm doing backups by making a copy of all the files, but I could improve it by exporting the feeds thanks to this CLI, and also backup the settings the status of the feeds (to save the unread list for instance).
Do you think that would be a good addition, as an extension to automate it, or if I should just document the cron tasks I'll use ?

edit: right, sorry for that :(

[Alkarex]

Please re-post this question in https://github.com/FreshRSS/FreshRSS/pull/1338 to keep things a bit organised :-)

[lapineige]

up :)

[Alkarex]

I tested without problem using FreshRSS 1.6.0-dev on:

• Windows 10 with Firefox 49, Internet Explorer 11, Edge 38, Chrome 55
• Ubuntu 16.04 with Firefox 49, Chromium 53, Midori 0.5.11
• Android 5.0.1 with Firefox 50, Chrome 54

However, there is a possible scenario, in which you click the "mark as read" button _before_ the JavaScript is loaded. The likelihood of that is much higher if you do not have appropriate HTTP caching policies. Can you check in your browser developer tools that JavaScript files such as main.js and jquery.min.js are served with caching, i.e. that there is no new request when you change page?

[Alkarex]

I will make a patch to prevent marking as read before scripts are loaded

[lapineige]

Can you check in your browser developer tools that JavaScript files such as main.js and jquery.min.js are served with caching, i.e. that there is no new request when you change page?

Yes they are served with caching (and if I delete the cache I get a 304 error). But I have a Cache Control header with max-age=0.
And even if I wait for them (and the whole page) to be fully loaded, no changes.

[Alkarex]

If you have a max-age=0 then you do not have full caching (only conditional requests). Many HTTP requests will still be needed, which are much reducing the performances. Try to wait in the console for the message "FreshRSS init done".
But then, you should fix your caching. See examples:
https://github.com/FreshRSS/FreshRSS/blob/dev/p/.htaccess
https://github.com/FreshRSS/FreshRSS/blob/dev/p/themes/.htaccess

[Alkarex]

You could please try this patch? https://github.com/FreshRSS/FreshRSS/pull/1344

[lapineige]

Try to wait in the console for the message "FreshRSS init done".

That's what I did.

But then, you should fix your caching. See examples:

Thanks, now I understand those error messages that I have when loading the page. I'm going to fix that.
Next I'll try your patch ;)

[lapineige]

Thanks, now I understand those error messages that I have when loading the page. I'm going to fix that.

I'm not able to fix it, I have no CSP rule defined, but it seems like it's coming from here. If I add one as open as possible, same situation (and with more restrictions, less things works, as expected).
(I asked on Yunohost forum for some help)

I have no idea how to solve this cache issue.

You could please try this patch? #1344

Not working, but it seem not compatible with my 1.5 version.
I have a new error.
TypeError: Argument 1 of MutationObserver.observe is not an object.
ytCinema.initialize() injected.js:57
<anonyme> injected.js:30

And the buttons no longer works (which btw solve the issue - in the hard way ^^)

[Alkarex]

Could you send me by e-mail an address where I can test the problem?

[Alkarex]

Let's close this issue, which has a patch in 1.6.0, and re-open another issue if the problems is still there in 1.7.0-dev.

[lapineige]

Let's close this issue, which has a patch in 1.6.0, and re-open another issue if the problems is still there in 1.7.0-dev.

I agree.
I'll test again with 1.7 ;)