Built-in report function should check user's settings and suggest to restore defaults? And to update lists?

[peace2000]

I wonder what is the reason behind this great deal of "Unable to reproduce" reports at uAssets repo: https://github.com/uBlockOrigin/uAssets/issues?q=label%3A%22unable+to+reproduce%22+

I have a few ideas that could potentially help to reduce them.

• Suggest the user to update all filter lists before sending a report (in the reporting tool) and add a button to update lists, next to "Find similar reports" button

• Before a user sends an issue report through uBO's reporting function, maybe uBO should check that the user has defaults and ask to restore them before sending a report (but not to force)? Obviously, everyone isn't truthful in the form that they have tried with defaults

• Also uBO could additionally send a list of installed other browser addons along with uBO-related settings and filterlists in use to the issue report? This could help to figure out if an issue could be caused by other addons. And maybe in some cases ask to disable specific addons if that addon is known for causing trouble. Especially, if multiple adblockers are being used. (Though, volunteers can always just close the issue report if the issue can't be reproduced.)

[gorhill]

uBO could additionally send a list of installed other browser addons

Not possible without adding a new management permission to the manifest, and I don't want to add such permission to uBO, people tend to react negatively when an extension asks for a new permission. It can be declared as an optional permission but I expect people to turn away when the browser ask to give a new permission to uBO and chose to not file a report.

For the two other ideas, I will give some more thought, I think a button to force an update of filter lists if they have not been recently updated would be useful.

[peace2000]

"Other extensions used" could imply that it's ok to send reports without disabling them.

[MasterKia]

At least permission is explicit to user.

There's a trade-off to be made, and the trade-off in this case is wasting volunteers time by having other conflicting extensions.

[gorhill]

It's no different than requesting the Management permission

It's doing something in a sneaky way which normally requires asking extensions API permission to users. Such behavior undermines trust, for good reasons. I would become suspicious of an extension doing this sort of thing to avoid asking my permission to do so.

However we could add a field for people to disclose other extensions used, and forcing them to write "none" if they don't have other extensions.

[MasterKia]

and forcing them to write "none" if they don't have other extensions.

Cool, I didn't know GitHub supported that.

[gorhill]

uBlockOrigin/uAssets@d066a45

[krystian3w]

I, for one, wonder if detection of active cosmetics has a similar limit imposed as someone with 80 lists - so as not to scare people with GitHub's http error.

[gorhill]

It's not done just for uBO filters, it's done for all stock filters: https://github.com/gorhill/uBlock/blob/1.49.3b17/src/js/messaging.js#L599-L603. Imported filter list (aka "external") are left out.

[dimisa-RUAdList]

I just checked, and indeed, the update happened for all active standard filters. But the imported filters were not updated. Is it possible to enable the update for them too?

[gorhill]

We are going back to my argument that we ask people to test issues without imported (external) filter lists, as we do not want to spend time investigating issue with non stock lists.

[dimisa-RUAdList]

I understand this argument. But since the filters are updated anyway, why not update them all, as if it were done in the 3p-filters.html tab? In addition, by clicking the update button, the user gets the false confidence that he has updated all the filters, when in fact this is not the case.

[peace2000]

@dimisa-RUAdList I agree. Why deliberately only update stock lists as the same function could be used to update all the lists?

Many people are not truthful (this is checked frequently):

I did not answer truthfully to ALL the above checkpoints.

Updating external lists could solve issues and we would see less unnecessary issue reports. Lessening issue reports that are caused by outdated lists was the idea of this discussion after all.

[gorhill]

Looking at recent https://github.com/uBlockOrigin/uAssets/issues reports, I can see it does seem to help, but amazingly there are still reports which just ignore the request to update filter lists. Should we just disable the Create new report button until the user did click Update now and the lists have been all updated? We will still have to trust that the user verified the issue still exist after lists have updated.

[krystian3w]

Some default lists are considered old, some are updated more than 4 times a day, waiting for GitHub actions.

[u-RraaLL]

@migozz

1. Screenshot the reporting widget showing your troubleshooting info.
2. Make sure you didn't disable default trusted sites.

When I open the settings, the update button is not active, which means that filters are always up-to-date. But the report button is not.

Not true. Filter lists and the reporting widget have different definitions of "outdated". We don't want people to abuse updating filter lists (mainly the issue has arisen due to youtube anti adblock last year). At the same time we don't want to receive duplicate reports for things that have already been fixed, which is why the widget requires a manual update.

[u-RraaLL]

Both ideas have been pitched before. The first one was rejected because (if I'm not mistaken) gorhill didn't want uBO to target any specific website within uBO's code (I'm not talking about scriptlets here). This could now be achieved using uritransform filters, but other team members were against that suggestion and were fine with the current bot actions.

For the second idea, I haven't received any feedback. Maybe because it was not a separate comment but a latter part of one that suggested renaming the YT megaissue back when they first started taking the detection globally.

[krystian3w]

In addition, tapping into other people's reports can be blocked by a private blacklist of first-time reporter e.g. 1+ year old issue.

Then someone may not feel the need to create an account for 7 days to discuss the problem and delete it account, so as not to irritate Microsoft.