@bernhard: Thanks for the report!!

Could you please help us with the sample page where you're seeing this issue and details of your device, if possible attach a screencast as well for further triaging of the issue.

Thanks!!

Hi, thanks for your response!
We are seeing this issue in our webapp running inside a webview but the issue can be reproduced on any webview with a web page running a service worker.
To reproduce the issue we have been using the following site: https://offline-news-service-worker.herokuapp.com/ All we need to do to recreate is to load this page in a webview and attach chromium's devtool. Open the console for the service worker and try to load a indexedDb:
self.indexedDB.open('db',1)
This will fail. Running the same command in the console for the main webpage works perfectly fine.

I've been testing this on Nexus 5X with Andoid 8.0 and WebView 62.0.3202.38.
We have also managed to reproduce the issue on a OnePlus with Android 6 and WebView  62.0.3202.38.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I came here to report exactly the same issue with accessing IndexedDB within a WebView, whilst being fine running in mobile Chrome on the same device.  I'm using Samsung Galaxy S6 and Chrome 62.0.3202.84

In the WebView's WebSettings I'm already calling all of the following with 'true':

setDatabaseEnabled
setAppCacheEnabled
setDomStorageEnabled
setJavaScriptEnabled

Thanks.

"DOMException: The user denied permission to access the database" comes when content settings disallows IndexedDB.

This seems likely caused by the work to add the content settings check to service workers around <https://crrev.com/a20ac9c693c4>.

I guess there was something we missed about handling the content settings for WebView?

I get no repro in SystemWebViewShell.apk with WebView 62.0.3202.38. Can you share an APK or code for an app that repros?

Hi,
thanks for looking into this. 

I have attached a very simple project with a WebView which reproduces the error.

See previous comment on how to use devtools to recreate the error. The important part is to open the indexedDB from the Service Worker console.

Deleted: ServiceWorker.tar.gz 15.4 MB

ServiceWorker.tar.gz 15.4 MB Download

Thank you for providing more feedback. Adding requester "paulmiller@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I get the same result in your app as with SystemWebViewShell.apk:

> self.indexedDB.open('db',1)
IDBOpenDBRequest {onblocked: null, onupgradeneeded: null, source: null, transaction: null, readyState: "pending", …}

Let me be more precise with the repro steps, to make sure we're doing the same thing:

1. Install WebView 62.0.3202.38 (and select it as the WebView implementation in the developer settings).
2. Run the SWtest app attached in #10.
3. Open chrome://inspect.
4. Under the Devices section, find "WebView in com.briteback.swtest (62.0.3202.38)".
5. Under that, find "Worker pid:<whatever> https://offline-news-service-worker.herokuapp.com/service-worker.js"
6. Under that, click "Inspect".
7. Run "self.indexedDB.open('db',1)" in the resulting console.

Is this correct?

Yes, those are the exact same steps and I uses the exact same WebView version.
Could you make sure the returned IDBOpenDBRequest does not contain an error?
This is what I get when expanding the result:
IDBOpenDBRequest {onblocked: null, onupgradeneeded: null, source: null, transaction: null, readyState: "pending", …}
error: DOMException: The user denied permission to access the database.
  code: 0
  message: "The user denied permission to access the database."
  name: "UnknownError"
__proto__:DOMException
onblocked: null
onerror: null
onsuccess: null
onupgradeneeded: null
readyState: "done"
result: undefined
source: null
transaction: null
__proto__: IDBOpenDBRequest

Yep.

> self.indexedDB.open('db',1)
▼ IDBOpenDBRequest {onblocked: null, onupgradeneeded: null, source: null, transaction: null, 
    readyState: "pending"…}
    error: null
    onblocked: null
    onerror: null
    onsuccess: null
    onupgradeneeded: null
    readyState: "done"
  ▶ result: IDBDatabase
    source: null
    transaction: null
  ▶ __proto__: IDBOpenDBRequest

It shouldn't matter, but what's your exact Android build? (Settings > System > About phone > Build number) And it also shouldn't matter, but which WebView provider are you using?

Android build number is OPR6.170623.023 (Nexus 5X, Android 8.0.0).
How can I find the WebView provider?

We have reproduced the issue on multiple devices, but I don't have them in front of me now (android 6 and android 7 I believe). We have also had multiple customer reporting the same issue.

Is there any other info we can provide to help reproduce the issue?

Settings > System > Developer options > WebView implementation (But if you don't know that means it's Chrome.)

A bugreport might help? Repro the bug and then run `adb bugreport`.

Yes WebView is Chrome 62.0.3202.38

I'll create a bugreport tomorrow when I get back to the office.

I can reproduce this with @bernhard's sample app.  I get exactly the same IDBOpenDBRequest returned as @bernhard.

Never mind. I got a Nexus 5X with OPR6.170623.023 (user) & Chrome 62.0.3202.38 and now I can repro. (I was previously using a Pixel with OPR1.170623.027 (userdebug) & WebView 62.0.3202.38.) This is interesting because none of those differences should matter.

I can also repro with WebView as the provider so that's not the important variable.

I did a bisect:

62.0.3202.38 - bad
62.0.3182.0 - bad
62.0.3181.0 - good
62.0.3180.0 - good
62.0.3179.2 - good
62.0.3177.0 - good
62.0.3173.0 - good
62.0.3164.0 - good
61.0.3163.128 - good

https://chromium.googlesource.com/chromium/src/+log/62.0.3181.0..62.0.3182.0?pretty=fuller&n=10000

The change linked in #7 is in the regression range. The author seems to have departed, so assigning to a reviewer.

The range includes the patch mentioned at c#7. The patch just reads the content settings of cookies as well as AllowServiceWorker(). If IndededDB access is denied, worker also should not be launched up. That seems wired...

https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?type=cs&q=AllowWorkerIndexedDB&sq=package:chromium&l=2134

#c21: I'm not sure that's right: the patch added the content settings check from service worker contexts which was previously never checked. I'm guessing the problem is ServiceWorkerContentSettingsProxyImpl::AllowIndexedDB.

In Chrome browser GetContentClient()->browser()->AllowWorkerIndexedDB probably goes to ChromeContentBrowserClient::AllowWorkerIndexedDB but in WebView it goes to  AwContentBrowserClient::AllowWorkerIndexedDB which is currently:

// Android WebView does not yet support web workers.
return false;

paulmiller/storage team: Any idea on the correct fix here?  I guess it wouldn't hurt for AllowWorkerIndexedDB to check use the cookie check like Chrome browser does?

Talked to boliu@ & torne@ and we think that WebView should actually be returning true in AllowWorkerFileSystem and AllowWorkerIndexedDB (those functions haven't been touched in 5 years) so I'll try that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/beea75e1f681c765b1f611b9feaa9c3b8e7a6732

commit beea75e1f681c765b1f611b9feaa9c3b8e7a6732
Author: Paul Miller <paulmiller@google.com>
Date: Tue Nov 21 03:24:29 2017

WebView: Remove worker restrictions from AwContentBrowserClient

AllowWorkerFileSystem and AllowWorkerIndexedDB are how Chrome
enables/disables features for particular domains. WebView settings
aren't per domain, so WebView doesn't need deny these features here.

Specifically, AllowWorkerIndexedDB was preventing Service Workers from
using IndexdDB, which is supported in WebView.

BUG= 783159 

Change-Id: I4fad21200e0dd5ceee4a3be86c3bb059a6908511
Reviewed-on: https://chromium-review.googlesource.com/775543
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Paul Miller <paulmiller@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518075}
[modify] https://crrev.com/beea75e1f681c765b1f611b9feaa9c3b8e7a6732/android_webview/browser/aw_content_browser_client.cc

I re-did the test in #12 with the above change and it works, so I'm calling this fixed. (It's not entirely proven to be fixed, though, because my repro was unreliable to begin with.)

The above change will be in m64 from now on (m64 is currently on 64.0.3274.0, so every version later than that). To get m64, install Chrome Canary and select it as your WebView provider (Settings > System > Developer options > WebView implementation).

Running bernhard's sample app and performing the steps of Comment 12, this still gives the exact same "permission denied" error as in Comment 13.

And I can confirm that I'm on the latest Canary Chrome webview implementation, because in step 4 of Comment 12 I am inspecting the service worker under the following heading:

WebView in com.briteback.swtest (64.0.3274.0)

re c#26: 
c#24 was initially in 64.0.3275.0. Please try it again after the next update.

My mistake, I jumped the gun.  Reading Comment 25 again, it does make it clear that the fix will be in every version *later than* 64.0.3274.0.  I'll try again in the next version.  

How does the Stable/Beta/Canary transition work?  If the magic number is 64.0.3275.0, after which it is again safe to use IndexedDB in our SW, will that be the same when the Canary eventually matures into Stable?  

So we can add a check for "Chrome/64.0.3275.0" (or greater) in User-Agent?

Conversely, from Comment 20, if the version number is from 62.0.3182.0 to 64.0.3274.0 (inclusive) then it is "bad".  Is that a sensible way of making this determination?

The version number is m.0.b.x where m = milestone, b = branch, and x is builds within that branch. A new branch is made from trunk ~daily. Milestone is incremented once per major release. Each milestone corresponds to the range of branches that were cut during that milestone e.g. 62 went from 62.0.3164.x to 62.0.3202.x and 63 went from 63.0.3203.x to 63.0.3239.x. The above change will be in every branch from 3275 onward (unless it gets reverted or merged to an earlier branch).

The channel (in order from most stable to freshest: stable, beta, dev, canary) a given version is released to doesn't change what branch it was built from, so 64.0.3275.0 and later will have the fix no matter the channel.

62.0.3182.x through 64.0.3274.x are bad, for any x values that exist.

You can see which channel is on which version here: https://omahaproxy.appspot.com/

Thanks for the explanation.

Looks good with the sample app and steps in Comment 12, with Chrome Canary version 64.0.3277.0 as WebView.  Output as attached.

And my actual service worker seems to be working fine now too.

Deleted: Capture.PNG 13.9 KB

	Capture.PNG 13.9 KB View Download

paul: Btw, do you think we should merge c#24 into beta?
The patch only changes two boolean to true and fixes the obvious regression, while I don't have any numbers of users who are using indexedDB on service workers on WebView.

+cmasso@ as to whether we want to merge.

The patch is simple but could there be any use cases we are missing here that make this change cause some breakages on stable? Also can we add some tests? 

I see we have AwServiceWorkerClientTest but I'm not sure how to detect this error in a test. timvolodine@, do you know?