Missing share menu with uBlock Origin

[szalat]

Steps to reproduce

1. Turn on uBlockOrigin 1.18.4 (chromium 72.0.3626.53 (Build) built on Debian buster/sid, running on Debian buster/sid (64 bit)
2. Go to nextcloud, select a file/folder, choose "share" icon
3. You see no "three dot" menu near each person that you share file with resulting no possibility to e.g unshare.

Expected behaviour

It should not be hidden.

Server configuration

Linux 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Nextcloud v. 15.0.5 fresh from Ubuntu Snap

List of activated apps:

~# nextcloud.occ app:list
Enabled:

• accessibility: 1.1.0
• activity: 2.8.2
• cloud_federation_api: 0.1.0
• comments: 1.5.0
• dav: 1.8.1
• federatedfilesharing: 1.5.0
• federation: 1.5.0
• files: 1.10.0
• files_pdfviewer: 1.4.0
• files_sharing: 1.7.0
• files_texteditor: 2.7.0
• files_trashbin: 1.5.0
• files_versions: 1.8.0
• files_videoplayer: 1.4.0
• firstrunwizard: 2.4.0
• flowupload: 0.0.9
• gallery: 18.2.0
• logreader: 2.0.0
• lookup_server_connector: 1.3.0
• metadata: 0.9.0
• nextcloud_announcements: 1.4.0
• notifications: 2.3.0
• oauth2: 1.3.0
• password_policy: 1.5.0
• provisioning_api: 1.5.0
• registration: 0.4.5
• serverinfo: 1.5.0
• sharebymail: 1.5.0
• socialsharing_email: 1.0.5
• socialsharing_facebook: 1.0.4
• socialsharing_twitter: 1.0.4
• survey_client: 1.3.0
• systemtags: 1.5.0
• theming: 1.6.0
• twofactor_backupcodes: 1.4.1
• workflowengine: 1.5.0
  Disabled:
• admin_audit
• encryption
• files_accesscontrol
• files_automatedtagging
• files_external
• files_rightclick
• support
• user_ldap

Nextcloud configuration:
~# nextcloud.occ config:list system
{
"system": {
"apps_paths": [
{
"path": "/snap/nextcloud/current/htdocs/apps",
"url": "/apps",
"writable": false
},
{
"path": "/var/snap/nextcloud/current/nextcloud/extra-apps",
"url": "/extra-apps",
"writable": true
}
],
"supportedDatabases": [
"mysql"
],
"memcache.locking": "\OC\Memcache\Redis",
"memcache.local": "\OC\Memcache\Redis",
"redis": {
"host": "REMOVED SENSITIVE VALUE",
"port": 0
},
"instanceid": "REMOVED SENSITIVE VALUE",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"removed",
"removed",
"removed"
],
"datadirectory": "REMOVED SENSITIVE VALUE",
"dbtype": "mysql",
"version": "15.0.5.3",
"overwrite.cli.url": "",
"dbname": "REMOVED SENSITIVE VALUE",
"dbhost": "REMOVED SENSITIVE VALUE",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"maintenance": false,
"mail_smtpmode": "smtp",
"mail_smtphost": "REMOVED SENSITIVE VALUE",
"mail_sendmailmode": "smtp",
"mail_domain": "REMOVED SENSITIVE VALUE",
"mail_from_address": "REMOVED SENSITIVE VALUE",
"skeletondirectory": ""
}
}

Are you using external storage, if yes which one: local/smb/sftp/...
local
Are you using encryption: yes/no
yes
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
no

Client configuration

Browser:
Chromium 72.0.3626.53 (Build) built on Debian buster/sid, running on Debian buster/sid (64-bit)
Operating system:
Linux 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux

[Faldon]

I can confirm this. It seems, the uBlock cosmetic filter is responsible for this. On disabling cosmetic filtering, the share menu is available as expected.
Tested this on Chromium 73.0.3683.75 on Arch Linux (Linux 5.0)

[Faldon]

Have got time now to investigate further.
I identified 3 elements that are blocked by uOrigin:

• .shareOption
• .share-menu
• #shareLink

These 3 elements are in Fanboy's Annoyance List as well as in Fanboy's Social Blocking List.
We can avoid this if we rename the concerned elements.

However:
Imho, I would not take this route. because:

1. In theory we had to dig through all filter lists and check, if the element names to be chosen are in neither one
2. This would not be a one time task, instead we had to constantly monitor the filter lists for changes
3. OR choose random generated element names where the probability for them to appear in a filter list is near zero
4. I, personally, whitelist my own domains in whole. Why shouldn't I trust what I am hosting on my own? Or, in case of enterprises, what the company is hosting.

But that's solely my own opinion for now.

[szalat]

Thank you, Faldon, for investigating issue.
I don't know which resolution is better but I would add my case:
It took me some time searching for "unshare" possibility. I was searching documentation, but it seemed too Simple, I could not find clear answer where button for unshare is or should be. I was checking my server's configuration, apache logs for errors...etc ... After few hours of trying i finally have disabled uBlock.
Maybe it should be mentioned in documentation or for example on configuration screen that use of adblocker could lead to some issues.

[Faldon]

I conform with you, that a notice in the documentation about possible problems when using an ad blocker seems appropriate.
Maybe @nextcloud/documentation has an idea, where such a message could be placed.

[anoadragon453]

Just got bitten by this as well. Was confusing me for months :)

[skjnldsv]

Fixed with #15719

[4jNsY6fCVqZv]

Will the fix also be rolled out for older, still supported Nextcloud versions or only for the upcoming version 18?

[kesselb]

I don't think so. It has been fixed as part of a bigger refactoring.

[bersbersbers]

I see this issue on NextCloud 18.0.9.1. Wasn't that supposed to be fixed?
18.0.9 was released in September 2020, a year after this fix.

[nico202]

I'm on Nextcloud v20.0.1, and had the same problem. Also, since uBlock report 0% of blocked elements, I couldn't even figure out the problem was uBlock: I thought my nextcloud install was broken