Uploaded PS5 with fixes for:
1. C++ compilation errors in input_method_controller.cc (const violation and missing include).
2. JNI Optional-to-String bug in ime_adapter_android.cc (passing null instead of empty string for absent optionals to preserve Java fallback logic).
3. Verified locally with JUnit tests.
Triggering CQ dry run.
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
ScopedJavaLocalRef<jstring> jstring_html_label =can you follow `jstring_text` for consistency?
private @Nullable String mHtmlLabel;
private @Nullable String mHtmlName;
private @Nullable String mHtmlId;
private @Nullable String mHtmlPlaceholder;feel like these often come together, probably can package them in a class.
mHtmlLabel = htmlLabel;
mHtmlName = htmlName;
mHtmlId = htmlId;
mHtmlPlaceholder = htmlPlaceholder;Can we move these to around line 825-811 for consistency?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
ScopedJavaLocalRef<jstring> jstring_html_label =can you follow `jstring_text` for consistency?
as in use value_or?
value_or one will return empty string for nullopt, but this will return null, which appears to be intentional?
String htmlLabel,these are @Nullable, as implemented on native side
if (htmlLabel != null) {how will these be used? does it make any sense to put some length limit on any of these? (maybe before it gets to java to be slightly more efficient)
if (htmlLabel != null) {are the null checks necessary?
} else if (htmlId != null) {I guess if only one is needed, more efficient to only send up one of them through jni
mojo_base.mojom.String16? html_label;should any of these be BigString?