[Done] Notify the maintainer of the filter

[alberto]

Last download attempt is currently all that Adblock Plus stores - time of last successful download isn't being saved. Maybe we should start now, this info is indeed useful.

Another aspect to consider is time reliability / local vs. server time. For example, someone could have configured their "correct" time but with wrong timezone (e.g. defaulted to GMT), and then the resulting UTC time will be misleading. I reckon the last download attempt has to be local time in order to control properly the update frequency. Going forward, the last successful download (if you decide to track it) should probably be based on server time.

[alberto]

Errors: I can probably censor file paths - replace the profile path by a placeholder. Maybe also the application path, just in case. That should be all as problematic cases go...

Another problematic case. This could reveal a link to another (private) report. As an example, this was an error attached in one of my reports (the report referenced was viewed few minutes before).

Warning
Unknown property 'border-radius'. Declaration dropped.
In https://reports.adblockplus.org/ef4d80c9-d072-4473-9d30-2f818fe1650d line 0

BTW, I guess the rationale for attaching errors is to detect filters with invalid CSS syntax that might break other (valid) rules. Do you have examples of such filters to try and see how this scenario would look on a report?

[Wladimir Palant]

The rationale is also to detect issues with Adblock Plus itself which might be responsible - that's the same information that chrome://adblockplus/content/errors.html is displaying. But I will make sure that errors referencing HTTP locations are ignored. Edit: fixed - https://hg.adblockplus.org/adblockplus/rev/7b6cef71e15f

Btw, I removed the existing reports because the directory structure changed - in case somebody is wondering.

[alberto]

Thanks for looking into this

Attaching a list of extensions: this isn't useful for false positives or missed ads but it could be valuable if "Other issue" is selected. So attaching this data in this (probably rare) case only might be a good idea. Any opinions on that?

I think this could be valuable in any scenario, not just "other issue". I believe in the past there had been extensions causing ABP to malfunction and users reporting missed ads (as opposed to missing icon etc). Examples: Ecosia removing subscriptions, the controversial NoScript case, and few others. Is anything preventing this to happen again?

[Wladimir Palant]

Examples: Ecosia removing subscriptions

The user would be submitting a report without any subscriptions - and I already plan special handling for that case. If the problem persists (like with Ecosia) the user would eventually send an "Other issue" report.

the controversial NoScript case

Would have shown up in the list of subscriptions.

few others

Breaks the user interface to the point where nothing will work, including sending of reports.

Is anything preventing this to happen again?

No. But this feature will be of limited use when investigating extension conflicts, not worth sacrificing privacy over it.

[Wladimir Palant]

Sending time of last successful subscription download and relative times is done: https://hg.adblockplus.org/adblockplus/rev/c5a412617a74
Example report: https://reports.adblockplus.org/ebee76f ... scriptions

Also different button title just before sending the report: https://hg.adblockplus.org/adblockplus/rev/99637795d351

Translating subscription names for user's filters and external subscriptions on the server: done

Censoring paths in error messages is done: https://hg.adblockplus.org/adblockplus/rev/94c7d1d6f76b

[alberto]

* Attaching a list of extensions

Fair point regarding usefulness vs. privacy. So if you wanted to direct anyone with a weird problem to post in the forum their extensions list (along side all the other stuff), would you provide a check box in issue reporter for this (which you would hate doing ) or to get this via other means e.g. about:support?

* Last successful download time

I think it would be more useful if displayed in absolute date/time than relative times (or have both).
As an example:
- say the subscription broke a popular website from date/time X, until date/time Y when it was fixed.
- therefore reports (linked to that website) with last successful download between time X and Y could be ignored (known cause), and eventually advise users to refresh their subscription
- maintainers would look at a batch of reports for the last day/week, they would be focusing on absolute times not relative times.

The email digest sent to maintainers (grouped by website?) could have the last successful download absolute date/time to filter them out easily

Anyway, maintainers, who obviously have more practical experience dealing with this, may have a different take on this.

[Wladimir Palant]

* Last successful download time

I think it would be more useful if displayed in absolute date/time than relative times (or have both).

Done, the absolute time is now visible in the tooltip. One shouldn't overestimate its precision however - the report can be sent a few hours after the incident happened (e.g. if that's the last time the user reloaded the page or he simply left the reporter dialog open during lunch).
Example report: https://reports.adblockplus.org/b4282de ... scriptions

[Wladimir Palant]

I think having a checkbox for extension list similarly to the one already there for the screenshot should be good enough as a solution, it makes things obvious. So I want to add a checkbox below the comment field: "Attach a list of my extensions in case an extension conflict is the cause". This checkbox should be pre-checked only if the selected type is "Other issue". Similarly, screenshot should no longer be pre-checked if "Other issue" is selected (the webpage is likely irrelevant).

[alberto]

Sounds like a good plan.

A couple of additional suggestions for improvement:

* Access to a local list of reports sent, like about:crashes
This could be handy to reference in forums later, check status, etc. Reports generated whilst on private browsing should not be tracked. Otherwise visited websites are tracked already in the browser history, so I think this would not introduce any privacy issues? Perhaps should delete this list if browser history is removed.

* Wizard - Step 2 - mark ad/sensitive data
When selecting and going beyond the edges, it just "locks" the selection at that point; it does not scroll down or let you continue and adjust the selection. This could help when selecting near the edges or marking a large vertical ad spanning multiple pages. I suspect there might be some technical limitations to implement this, but thought I will mention it just in case.

[Michael]

On Linux, if the window is maximised the progress bar and text will be stretched horizontally. This issue is especially noticeable on the screenshot page, as the image generated is also distorted by the stretching applied to the window.

[Wladimir Palant]

Michael, this window isn't supposed to be resizable, I'll check...

[Michael]

In my experience almost every window opened on Linux is resizeable.

[Wladimir Palant]

Argh, you are right... At least on SUSE Linux resizable=no flag is completely ignored, the window can be freely resized. I guess all I can do there is ensuring that it doesn't get too ugly then.

Edit: Done - https://hg.adblockplus.org/adblockplus/rev/0654d49309a6

Edit2: Recently submitted reports are now displayed on the first page of the wizard: https://hg.adblockplus.org/adblockplus/rev/86c19b793a7c

Edit3: Extensions can now be attached (default is "attach" for "other issue" only): https://hg.adblockplus.org/adblockplus/rev/eb75e3cb572b

[alberto]

Thanks for implementing the recently submitted reports feature. I think it will look better (less clutter) if it shows only a link that then expands into the list when clicked (similar to the 'show report data' in step 3). Also, you may want to consider showing 'other issue' instead of the website if it it an 'other issue' report (your rationale was that the website is most likely irrelevant in that case).