Disabling background clipboard may be interfering with ability to paste strings into Chromium from other apps

[craftyguy]

Here's an example of a typical workflow I have been using with other browsers (Firefox, Lightning Browser, etc) and other apps (my bank's mobile app for instance):

1. Run application or open website in browser

2. Prompted for password, switch to Password Store

3. Find/copy relevant password from Password Store

4. Switch back to app or site in browser, paste in password and continue on

When using Chromium, step 4 seems to work properly once. If I repeat the steps again (e.g. because I went to a different site that requires a different password), it doesn't work and will keep pasting in the previous string no matter how many times I copy a new string from a different application. If I switch the setting to allow background access to the clipboard, then it works as expected, but this is an undesirable workaround.

Also worth noting that this is just an example of one workflow where this is funky. It works if I try to copy text from any app and paste it into Chromium (either url bar or form in a page)

I've only recently re-enabled and started using the Chromium build in COS, so unfortunately I do not know when this behavior started exactly.

I also do not know enough about your intended usage model for this feature to know if this is expected behavior or not. I assumed it was not, since this seems to be very specific to Chromium and does not happen with other applications I have tried. Since the setting is "background clipboard access", I was expecting that only apps in the background would be denied permission to the clipboard, since in my example workflow both the password manager app and chromium are in the foreground when I initiate the copy/paste actions.

Tried to look at the source code in COS, but I'm really not familiar with where this was implemented (I think you said it may have been an upstream feature ??).

COS version: N2G47X.2017.06.15.06.09.53
Device: Nexus 5X

[thestinger]

It's implemented at CopperheadOS/platform_frameworks_base@5d34cda. I don't know why it would cause problems for Chromium. I reused a pattern that they already used elsewhere.

[thestinger]

It's implemented at CopperheadOS/platform_frameworks_base@5d34cda. I don't know why it would cause problems for Chromium. I reused a pattern that they already used elsewhere.

[thestinger]

I'll add some logging to help with debugging it. I don't have time to work on permission model changes anymore though. For example, I abandoned the toggle to disable permissions for legacy API level apps by default because there were some issues and it needed to be approached differently.

[thestinger]

I'll add some logging to help with debugging it. I don't have time to work on permission model changes anymore though. For example, I abandoned the toggle to disable permissions for legacy API level apps by default because there were some issues and it needed to be approached differently.

[thestinger]

If you grep for isForegroundActivity in frameworks/base, you'll see that I took it from services/core/java/com/android/server/fingerprint/FingerprintService.java. If I was doing it upstream, it would get moved somewhere to reuse the code, but for downstream changes refactoring / code reuse that makes changes more invasive is bad.

[thestinger]

If you grep for isForegroundActivity in frameworks/base, you'll see that I took it from services/core/java/com/android/server/fingerprint/FingerprintService.java. If I was doing it upstream, it would get moved somewhere to reuse the code, but for downstream changes refactoring / code reuse that makes changes more invasive is bad.

[thestinger]

If #307 was implemented that would be a workaround for this. I haven't confirmed that I can replicate this problem yet though.

[thestinger]

If #307 was implemented that would be a workaround for this. I haven't confirmed that I can replicate this problem yet though.

[craftyguy]

Thanks for looking into this a little, and for your insights.

If #307 was implemented that would be a workaround for this. I haven't confirmed that I can replicate this problem yet though.

This goes to show how little I know/understand in this area.. but it looks like this ticket is referring to a way to block background access to the clipboard.. which I thought was already implemented or is this ticket referring to something else?

I haven't confirmed that I can replicate this problem yet though.

I'll continue trying things to see if I can characterize a more specific set of instructions for reproducing it. Right now it seems to happen every time I try to paste into Chromium from another app (which was copied from in the foreground).

[craftyguy]

Thanks for looking into this a little, and for your insights.

If #307 was implemented that would be a workaround for this. I haven't confirmed that I can replicate this problem yet though.

This goes to show how little I know/understand in this area.. but it looks like this ticket is referring to a way to block background access to the clipboard.. which I thought was already implemented or is this ticket referring to something else?

I haven't confirmed that I can replicate this problem yet though.

I'll continue trying things to see if I can characterize a more specific set of instructions for reproducing it. Right now it seems to happen every time I try to paste into Chromium from another app (which was copied from in the foreground).

[thestinger]

@craftyguy It's referring to having a dangerous permission to override the global toggle, so then apps could be marked as requesting the permission and there would be a per-app toggle for those apps.

[thestinger]

@craftyguy It's referring to having a dangerous permission to override the global toggle, so then apps could be marked as requesting the permission and there would be a per-app toggle for those apps.

[thestinger]

Basically, the aim would be getting apps to adopt the permission and then we could eventually remove the global toggle.

[thestinger]

Basically, the aim would be getting apps to adopt the permission and then we could eventually remove the global toggle.

[craftyguy]

Ah, I see, that makes sense. Well, I had a hard time building chromium some number of months back and have not tried again since then, and shied away from trying to build COS. I should have time next week to try again.
If I wanted to try to implement something like #306, there really isn't a good way to test that if I only have 1 COS-supported device (which is my daily driver), huh? Do you use physical devices to do incremental testing during development, or run COS in an emulator?

[craftyguy]

Ah, I see, that makes sense. Well, I had a hard time building chromium some number of months back and have not tried again since then, and shied away from trying to build COS. I should have time next week to try again.
If I wanted to try to implement something like #306, there really isn't a good way to test that if I only have 1 COS-supported device (which is my daily driver), huh? Do you use physical devices to do incremental testing during development, or run COS in an emulator?

[thestinger]

You could build CopperheadOS for the Android emulator but I haven't tried to do it for a while. I fixed a couple x86 compatibility issues a long time ago to make it possible.

[thestinger]

You could build CopperheadOS for the Android emulator but I haven't tried to do it for a while. I fixed a couple x86 compatibility issues a long time ago to make it possible.

[thestinger]

I use physical devices. Ideally, I'd have at least two of every device we support. One running signed, production builds with a locked bootloader (but OEM unlocking enabled to avoid bricking it) and another running test key signed userdebug builds with an unlocked bootloader to avoid needing to build OTA updates to sideload, since that adds a lot of time.

[thestinger]

I use physical devices. Ideally, I'd have at least two of every device we support. One running signed, production builds with a locked bootloader (but OEM unlocking enabled to avoid bricking it) and another running test key signed userdebug builds with an unlocked bootloader to avoid needing to build OTA updates to sideload, since that adds a lot of time.

[thestinger]

I added logging so this will be in adb logcat the next release (whenever that is) when it denies access:

06-17 04:23:26.987   977  1609 E ClipboardService: denied background clipboard access for com.catchingnow.tinyclipboardmanager, pid 2849

[thestinger]

I added logging so this will be in adb logcat the next release (whenever that is) when it denies access:

06-17 04:23:26.987   977  1609 E ClipboardService: denied background clipboard access for com.catchingnow.tinyclipboardmanager, pid 2849

[thestinger]

This is released: https://www.reddit.com/r/CopperheadOS/comments/6i3zpm/copperheados_n2g47x20170618220437_release_nexus/.

[thestinger]

This is released: https://www.reddit.com/r/CopperheadOS/comments/6i3zpm/copperheados_n2g47x20170618220437_release_nexus/.

[craftyguy]

I've installed the update and reproduced the issue, output from logcat when I tap 'paste' when in chromium is below. There's no output from ClipboardService.

06-19 16:10:41.584  8979  8979 E DecorView[]: Destroying unexpected ActionMode instance of TYP
E_FLOATING; com.android.internal.view.FloatingActionMode@6d34750 was not the current floating
action mode! Expected null
06-19 16:10:41.640  9034  9034 W Thread-2: type=1400 audit(0.0:451): avc: denied { read } for
name="stats" dev="proc" ino=4026535921 scontext=u:r:untrusted_base_app:s0:c512,c768 tcontext=u
:object_r:proc_net:s0 tclass=file permissive=0
06-19 16:10:41.758  8979  9019 D OpenGLRenderer: endAllActiveAnimators on 0x780b92d000 (Ripple
Drawable) with handle 0x780b719cc0
06-19 16:10:43.383  9034  9034 W Thread-2: type=1400 audit(0.0:452): avc: denied { read } for
name="stats" dev="proc" ino=4026535921 scontext=u:r:untrusted_base_app:s0:c512,c768 tcontext=u
:object_r:proc_net:s0 tclass=file permissive=0
06-19 16:10:43.440  9034  9034 W Thread-2: type=1400 audit(0.0:453): avc: denied { read } for
name="stats" dev="proc" ino=4026535921 scontext=u:r:untrusted_base_app:s0:c512,c768 tcontext=u
:object_r:proc_net:s0 tclass=file permissive=0

I seem to get that exact same output from in the log after attempting a paste in chromium; I tried on 4 different occasions to make sure those messages were actually associated with the 'paste event' and not spurious messages that just happened to coincide with the event.

[craftyguy]

I've installed the update and reproduced the issue, output from logcat when I tap 'paste' when in chromium is below. There's no output from ClipboardService.

06-19 16:10:41.584  8979  8979 E DecorView[]: Destroying unexpected ActionMode instance of TYP
E_FLOATING; com.android.internal.view.FloatingActionMode@6d34750 was not the current floating
action mode! Expected null
06-19 16:10:41.640  9034  9034 W Thread-2: type=1400 audit(0.0:451): avc: denied { read } for
name="stats" dev="proc" ino=4026535921 scontext=u:r:untrusted_base_app:s0:c512,c768 tcontext=u
:object_r:proc_net:s0 tclass=file permissive=0
06-19 16:10:41.758  8979  9019 D OpenGLRenderer: endAllActiveAnimators on 0x780b92d000 (Ripple
Drawable) with handle 0x780b719cc0
06-19 16:10:43.383  9034  9034 W Thread-2: type=1400 audit(0.0:452): avc: denied { read } for
name="stats" dev="proc" ino=4026535921 scontext=u:r:untrusted_base_app:s0:c512,c768 tcontext=u
:object_r:proc_net:s0 tclass=file permissive=0
06-19 16:10:43.440  9034  9034 W Thread-2: type=1400 audit(0.0:453): avc: denied { read } for
name="stats" dev="proc" ino=4026535921 scontext=u:r:untrusted_base_app:s0:c512,c768 tcontext=u
:object_r:proc_net:s0 tclass=file permissive=0

I seem to get that exact same output from in the log after attempting a paste in chromium; I tried on 4 different occasions to make sure those messages were actually associated with the 'paste event' and not spurious messages that just happened to coincide with the event.

[thestinger]

It might break the clipboard app earlier by denying it access?

[thestinger]

It might break the clipboard app earlier by denying it access?

[craftyguy]

Oh, hmm, let me try to devise an experiment to try this and capture logcat. logcat is just SUPER spammy so it's hard to correlate things I do with the noise it spews out. I'll try to set a filter for the clipboard app.

[craftyguy]

Oh, hmm, let me try to devise an experiment to try this and capture logcat. logcat is just SUPER spammy so it's hard to correlate things I do with the noise it spews out. I'll try to set a filter for the clipboard app.

[craftyguy]

So I now see the denial:

06-19 16:26:16.946 5310 6374 E ClipboardService: denied background clipboard access for org.
chromium.chrome, pid 10357

The interesting bit, since I have no idea how ClipboardService does its thing, is that this prints to logcat when I switch to another app (I tried a text editor & the search box on my home screen), and tap 'copy' on some text I have selected.

The experiment I did was:

1. Force close chromium (if previously running)

2. open chromium

3. switch to any app with text

4. select text, tap 'copy'. The clipboard service denial message is printed here

5. Switch to chromium, copied text in step 4 will successfully paste. (no interesting messages in logcat)

6. Repeat from step 3-5, selecting new text, new text does not paste in chromium (but old text does). I see the clipboard service reject the request for background access again when tapping 'copy' in other app, and the messages in my previous comment are also printed when I tap 'paste' in chromium

I also tried the same experiment without any filtering in logcat and observed that this is the only message printed when I tap 'copy' within another app.

[craftyguy]

So I now see the denial:

06-19 16:26:16.946 5310 6374 E ClipboardService: denied background clipboard access for org.
chromium.chrome, pid 10357

The interesting bit, since I have no idea how ClipboardService does its thing, is that this prints to logcat when I switch to another app (I tried a text editor & the search box on my home screen), and tap 'copy' on some text I have selected.

The experiment I did was:

1. Force close chromium (if previously running)

2. open chromium

3. switch to any app with text

4. select text, tap 'copy'. The clipboard service denial message is printed here

5. Switch to chromium, copied text in step 4 will successfully paste. (no interesting messages in logcat)

6. Repeat from step 3-5, selecting new text, new text does not paste in chromium (but old text does). I see the clipboard service reject the request for background access again when tapping 'copy' in other app, and the messages in my previous comment are also printed when I tap 'paste' in chromium

I also tried the same experiment without any filtering in logcat and observed that this is the only message printed when I tap 'copy' within another app.

[thestinger]

It would be helpful to look at adb shell ps -Z and list out the Chromium processes to match that PID to a process.

[thestinger]

It would be helpful to look at adb shell ps -Z and list out the Chromium processes to match that PID to a process.

[thestinger]

This is now using Google's code for background clipboard access denial, used for instant apps. The only part that's now our feature is extending it to other apps.

[thestinger]

This is now using Google's code for background clipboard access denial, used for instant apps. The only part that's now our feature is extending it to other apps.

[xbtc-im]

Yes, but it looks like this only happens with Chromium / WebView. All other apps are working fine ...

[xbtc-im]

Yes, but it looks like this only happens with Chromium / WebView. All other apps are working fine ...

[xbtc-im]

BTW, if you select the address bar in Chromium, you can copy/paste it.
Also, copy/paste FROM Chromium address bar to the actual page, and FROM address bar to a different app, is working.
Same goes FROM a different app to a form in Chromium ...
But nothing goes out from the actual displayed page / content ...

[xbtc-im]

BTW, if you select the address bar in Chromium, you can copy/paste it.
Also, copy/paste FROM Chromium address bar to the actual page, and FROM address bar to a different app, is working.
Same goes FROM a different app to a form in Chromium ...
But nothing goes out from the actual displayed page / content ...

[thestinger]

You're not describing the issue here. This is about the background clipboard access feature, which applies to all clipboard operations in the same way. If you have background clipboard access enabled and your issue is still happening, there's no relation to this, where the denials were logged when it happened. The cause of this issue is known and this issue is probably fixed in Oreo. If you have a different problem not tied to background clipboard access, it doesn't belong in this issue.

[thestinger]

You're not describing the issue here. This is about the background clipboard access feature, which applies to all clipboard operations in the same way. If you have background clipboard access enabled and your issue is still happening, there's no relation to this, where the denials were logged when it happened. The cause of this issue is known and this issue is probably fixed in Oreo. If you have a different problem not tied to background clipboard access, it doesn't belong in this issue.

[xbtc-im]

Allright, i get it now. Wrong place for the issue.

[xbtc-im]

Allright, i get it now. Wrong place for the issue.

[thestinger]

I don't think this old background clipboard access issue is present anymore. Google added their own code for this and we're now using that.

[thestinger]

I don't think this old background clipboard access issue is present anymore. Google added their own code for this and we're now using that.

[thestinger]

I think instant apps can use WebViews and the WebView is using the multiprocess sandbox in stock Oreo so the code is now being tested on stock where @craftyguy was hitting an issue before. All we're doing is extending this to normal non-instant apps and adding denial for logging.

[thestinger]

I think instant apps can use WebViews and the WebView is using the multiprocess sandbox in stock Oreo so the code is now being tested on stock where @craftyguy was hitting an issue before. All we're doing is extending this to normal non-instant apps and adding denial for logging.

[xbtc-im]

Yes, you are correct, it's not related to this issue.

[xbtc-im]

Yes, you are correct, it's not related to this issue.