Open johannesjo opened 1 month ago
jiongxuan
commented
1 month ago Thanks for bringing this up!
For now, let’s hold off on releasing the new version until we’ve fully resolved this issue. I’ll work on verifying the problem and try to fix it as soon as possible.
Also, thank you for your thorough testing, and I appreciate your efforts to test it further.
(You can assign this bug to me)
johannesjo
commented
1 month ago As a related question: Would it be alright to remove the isDebugBuild condition from the config.gradle in these lines:
// Set the service host based on the build type and whether it's running locally
def serviceHost = (serviceIsLocal == "true" && isDebugBuild) ? "10.0.2.2:4200" : appConfig.getProperty("ONLINE_SERVICE_HOST", "app.super-productivity.com")
// Set the protocol based on the build type and whether it's running locally
def serviceProtocol = (serviceIsLocal == "true" && isDebugBuild) ? "http" : appConfig.getProperty("ONLINE_SERVICE_PROTOCOL", "https")or am I overlooking something?
As an update for the issue: I don't understand why but running on a different emulator (Pixel 6, API 30) does not resolve the issue on that particular device, but the error persists.
jiongxuan
commented
1 month ago I tested the upgrade from the old version to the new one on both a Xiaomi 14 Pro and a Pixel 8 emulator, following the same steps, but I couldn’t reproduce the issue. In the old version, I specifically enabled WebDAV and confirmed via the Console that the Service Worker was loaded. After upgrading to the new version, I verified that the app was using the compatible URL (https://app.super-productivity.com), just like in your screenshots.
From the logs and screenshots, it appears that the compatible solution (https://app.super-productivity.com) is being loaded, but the issue might be related to a JavaScript parsing error, potentially caused by caching.
Since you’re upgrading from an older version, could you provide details about the exact version you upgraded from, what actions you took, and the steps after the upgrade? Having a complete reproduction flow would help me track down the issue more effectively.
Just to add, I tested this in both 5G and WiFi environments, and there were no network-related issues on my end.
jiongxuan
commented
1 month ago I also wanted to share the steps I followed during my testing:
I’ll try using a Release build later, but I assume the result will be similar. Could you check if these steps align with yours?
jiongxuan
commented
1 month ago Regarding your question about removing the isDebugBuild condition from config.gradle, my understanding is that this issue might not be directly related to that code. Here’s why:
Previous Deployment: This particular logic has been deployed since last month, and there were no changes in this area during the current release. In the compatibility mode, the logic remains the same as before.
Importance of the Condition: I wouldn’t recommend removing this section. It defines the scheme for the service based on the build type and environment (local or remote). If removed, it could revert back to the earlier state, where multiple modifications would need to be made in FullScreenActivity to ensure proper URL handling. This would increase the risk of inconsistencies.
That said, to be thorough, could you double-check the code changes just to ensure nothing else was unintentionally modified? It’s currently midnight here, so I’ll take a closer look at it tomorrow morning.
Also, feel free to provide any additional reproduction details and logs. It would help us narrow down the issue more effectively.
As a related question: Would it be alright to remove the
isDebugBuildcondition from theconfig.gradlein these lines:// Set the service host based on the build type and whether it's running locally def serviceHost = (serviceIsLocal == "true" && isDebugBuild) ? "10.0.2.2:4200" : appConfig.getProperty("ONLINE_SERVICE_HOST", "app.super-productivity.com") // Set the protocol based on the build type and whether it's running locally def serviceProtocol = (serviceIsLocal == "true" && isDebugBuild) ? "http" : appConfig.getProperty("ONLINE_SERVICE_PROTOCOL", "https")or am I overlooking something?
As an update for the issue: I don't understand why but running on a different emulator (Pixel 6, API 30) does not resolve the issue on that particular device, but the error persists.
jiongxuan
commented
1 month ago Maybe we can try a different approach.
Could you generate the FDroid Release APK (since you have the signing certificate, you’d need to generate it yourself) and then test it against the previous FDroid installation package? This way, we can at least confirm whether the final user-facing APK has the same issue.
If the final release package works fine and only the testing builds have the issue, I personally think we can proceed with the release. We can then analyze the issue in the test builds afterward.
This would ensure stability for end users while still allowing us to continue investigating. What do you think?
（One more thing: I suggest not using npm run buildFrontend:stageWeb:unminified to generate the release package, as this command is mainly for generating debug-related builds. I’ve been using npm run dist:android:prod to create, so you might want to try that as a reference.）
johannesjo
commented
1 month ago So I spend quite some time digging into this. The error has nothing to do with the changes you made, but depends on the webkit version. This interestingly seems to be completely independent from the android SDK version. My pixel 4 emulator with SDK29 had a newer webkit version than my pixel 6 emulator with SDK30. For newer versions (Starting with 113.0.5672.136 and possibly earlier) there is no issue. For older versions there are problems, because we are using ES2022 and not all the new syntax is supported in older webkit versions.
So it's a web frontend issue :) Sorry for bothering you with this!!
Do you have by chance any knowledge of the market share of different webkit versions?
ChatGPT says:
Android 7.0 (Nougat) and above: Devices can use either the standalone WebView or the Chrome browser as the WebView implementation. This means the WebView version can be tied to the version of Chrome installed on the device.
Android 10 (Q) and above: The WebView component is updated more frequently and independently of the system updates, ensuring that users have the latest version with security patches.
If this is true this sounds like we should be fine for the most part and can just continue with the release. What do you think?
jiongxuan
commented
1 month ago I’m glad we’ve pinpointed the root cause.
Trues be told, when I was reviewing the Logcat logs yesterday, I noticed these lines:
Loading com.android.chrome version 61.0.3163.98 (code 316409812)
[INFO:CONSOLE(1)] "Uncaught SyntaxError: Unexpected token {", source: https://app.super-productivity.com/polyfills-OXW65WWX.js (1)
Given my dev experience with mobile browsers, I suspected it could be a JSC/V8 version issue, especially since Chrome 61 is quite old (released in September 2017), that the underlying V8 engine in this version doesn’t support the newer JavaScript features introduced in ES2022.
However, since you mentioned the issue occurred after upgrading from an older version, I initially thought the older version was working fine and didn’t consider the WebKit angle further.Next time, I’ll be sure to include all potential causes—sorry for overlooking this!
In my experience working on large-scale apps, we have two main options:
(Recommended) Using Babel to transpile the JavaScript to ES5/ES6 for broader compatibility.
Bundling a Chromium WebView within the app, which is a common solution in large Chinese applications to solve compatibility issues.
That said, bundling Chromium isn’t really suitable for our project, so I’d strongly recommend focusing on Babel for compatibility.
Regarding WebKit version distribution, I don’t have recent global data (my latest is from 2019), and I’m more familiar with the Chinese market. However, I believe Babel transpilation should be sufficient to cover most cases.
Lastly, since WebView updates are now independent on most devices, I don’t think this will block the release. We can address the compatibility issue with Babel in future iterations.
What do you think? 😄
johannesjo
commented
1 month ago I agree with you. I added support for a bit older browser engines (chrome 83, which came out in 2020). I think most android users should have a newer version installed anyway, so maybe in the future we can ditch this completely.
I will try to make a new release now so we can test this out!
jiongxuan
commented
1 month ago Sounds good! Looking forward to testing the new release.
johannesjo
commented
1 month ago I made a release for 10% of the android users just now. Fingers crossed that all goes well! :)
jiongxuan
commented
1 month ago To be honest, currently these 10% or more users are only using the compatibility mode. The real challenge lies with those new users who will directly use the brand new Connectivity-Free mode.
Let's keep praying for continuous smoothness! 🚀
Hey @jiongxuan ! I encountered some issues with the new build and was hoping you could help. After merging all the PRs and the repositories I did the following:
npm run buildFrontend:stageWeb:unminified && npx cap syncapp_config.properties. The old version of the app was present with some data.This resulted in the errors bellow.
I can reliably reproduce this for every restart and re-deployment of the app.
I had the suspicion that this has to do something with the previously installed service workers but uninstalling them as well as deleting all the data from
chrome://inspect/#deviceshas no effect.The issue is fixed by deploying and running the app once with
LAUNCH_MODE=2andONLINE_SERVICE_IS_LOCAL=false. After that I can run the app with the default settings and all works fine.Any clues what might cause that? Do you think this would affect users when deploying a new android app?
Devtools:
Logcat: