uazo
commented
1 week ago try activating (or deactivating) vulkan, do you know how?
Open danielk43 opened 1 week ago
uazo
commented
1 week ago try activating (or deactivating) vulkan, do you know how?
danielk43
commented
1 week ago Thanks. Did you mean this gn arg?
enable_vulkan
Current value (from the default) = true
From //gpu/vulkan/features.gni:11
Enable experimental vulkan backend.no need to recompile, try with:
adb shell am start -a "com.android.webview.SHOW_DEV_UI"unfortunately I'm stuck, I can no longer activate the webview in the emulator... any suggestions?
danielk43
commented
1 week ago Not for the emulator issue, sorry. Will try your suggestions on my side shortly, first without recompiling
danielk43
commented
1 week ago I was able to launch the WebView DevTools UI:
$ adb shell am start -a com.android.webview.SHOW_DEV_UI
Starting: Intent { act=com.android.webview.SHOW_DEV_UI }and changed WebViewVulkanIntermediateBuffer from Default to Enabled then to Disabled with no luck. Did not see any other Vulkan options under WebView Flags.
Will keep looking into it.
This might help if it is not launching
uazo
commented
1 week ago the problem is on my side. in the next release the webview will start working again. thanks for the report.
uazo
commented
1 week ago if you are interested, this is what you need to add to your build if you want to make it work:
--- a/components/variations/service/variations_field_trial_creator_base.cc
+++ b/components/variations/service/variations_field_trial_creator_base.cc
@@ -331,6 +331,8 @@ bool VariationsFieldTrialCreatorBase::SetUpFieldTrials(
safe_seed_manager, synthetic_trial_registry);
}
+ platform_field_trials->RegisterFeatureOverrides(feature_list.get());
+
base::FeatureList::SetInstance(std::move(feature_list));
// For testing Variations Safe Mode, maybe crash here.
Nice! I see where that was removed in the Disable-fetching-of-all-field-trials patch. Will add it back and confirm.
danielk43
commented
1 week ago WebView is now loading for me, and also when packaged as Trichrome. Thank you for the fix.
uazo
commented
1 week ago I would like to experiment with an idea for fast replacement of the webview implementation in the source code, for use by all opensource projects that use the webview (e.g. duckduckgo browser but also stoutner's privacy browser), but I don't have time.
do you have the will/skills? In case I can expose my idea.
danielk43
commented
1 week ago I'd feel comfortable if there was a working example somewhere which could be adapted. If creating from scratch it would be challenging, but maybe. I'd be willing to try, at least. It sounds like an OS-level change though, no? Similar to some projects connectivity check settings but also enforcing build signature, etc.
uazo
commented
1 week ago no, code-side not system-side. the last one does not seem possible in non-rooted android.
everything I write is to be verified:
see getWebViewContextAndSetProvider() would appear to be the method used by the webview component to retrieve the implementer.
the assumption is that that code runs under the current application, so Application initialApplication = AppGlobals.getInitialApplication(); is the application context.
the idea is to do an override of getPackageManager() and getSystemService() (perhaps via ContextWrapper) and in retrieving pm.getPackageInfo() send the information in PackageInfo with the data of the new webview.
the hope is that Flags.updateServiceIpcWrapper() is enabled by default and it is possible to do the override of the application context and that the android framework does not do any other checks on the validity of the signature or the location of the webview apk (but that Context.CONTEXT_IGNORE_SECURITY in code gives me some hope).
I realise that there are many ‘maybes’... If I had the time I would try it with the system_webview_shell.
danielk43
commented
1 week ago Thanks for the details. The methods are new for me but conceptually it makes sense. Will begin looking this week and try to get into it a bit. Collab from anyone is welcome also.
Preliminary checklist
Can the bug be reproduced with corresponding Chromium version?
Yes
Are you sure?
Yes
Cromite version
128.0.6613.114
Device architecture
arm64
Platform version
Android 13
Android Device model
Pixel 5a (barbet)
Is the device rooted?
No
Changed flags
no flags changed
Is this bug happening in an incognito tab?
No
Is this bug caused by the adblocker?
No
Is this bug a crash?
Describe the bug
I have been following your Webview updates, thanks for working on it. Something like this patch should fix the current build error for arm64.
After that it builds but once installed, it crashes. See debug log. I am not actually sure if it's related to AdBlocker but I have no control over it in WebView. Also I am building it into the OS and allowing it in config_webview_packages.xml. It shows as active/selected in Settings > System > Developer options > WebView implementation
Steps to reproduce the bug
1) Build, install, allow, and set Cromite as webview provider. 2) Open app which requires webview, observe crash. Confirm in adb logs
Expected behavior
Expected applications which rely on system webview to open and load content.
Screenshots
No response