New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 789754 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Mar 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Missing ForOMR1 classes in WebView

Project Member Reported by ntfschr@chromium.org, Nov 29 2017

Issue description

Our most recent build (64.0.3280.3) is missing ForOMR1 classes in WebView. I talked with John, we agree this was a side effect of 17cfa616d9f7bc428e4525be26979bff8eb8fbd7.

This means that anyone using MonochromeCanary as a WebView provider on OMR1 will get a runtime crash. I expect the number of real users in this state to be pretty small.

Short term solution:

Upstream the ForOMR1 classes. I'm doing this already for  issue 782525 . This will fix the problem completely.

Long term solution (for P and beyond):

We're currently gating our next-GN file on "public_android_sdk == false". In the future, we should actually gate on SDK level (e.g. > 27). If we don't like guessing what the SDK int will eventually be, we can do something like 'if (android_sdk_release == "p")'.

---

I'll take this until I'm done upstreaming, I'll chat with Torne and John about implementing the fix for P and beyond.
 
Labels: M-64 ReleaseBlock-Dev
Adding a blocker label because I don't think we should put out any more releases in this state. Feel free to adjust the label as necessary.

Comment 2 by cmasso@google.com, Nov 30 2017

The fix will be included in tomorrow's dev which was delayed due to another blocker. So we are covered here.
Labels: -ReleaseBlock-Dev
Owner: torne@chromium.org
Ok, the classes are upstreamed (satisfying the short term solution). Removing the blocker label.

Keeping this open and passing to Torne to fix the GN logic (code search link [1]) as he lands ForP classes.

[1] https://cs.corp.google.com/search/?q=package:clankium+f:clank+f:gni?$+if.*public_android_sdk&type=cs
Owner: ntfschr@chromium.org
I'll steal this back, since I can land the ForP provider. I'll try to make the SDK-level check more robust at the same time.
Labels: -Pri-1 -M-64 Pri-3
To clarify, the immediate issue was resolved in  issue 782525 .

I'll use this issue to track improving the GN logic. This part is non-urgent, so I'm lowering priority.
Unfortunately, I don't have any good ideas for changing GN logic. It would be nice to use ">=" comparisons against ints, but it's not safe to assume that "P" will be 28 until it's actually finalized in Android.

I think we may just need to be more careful going forward during upstreaming. I've updated instructions at go/clank-webview/next-layers to warn about this and suggest mitigations.
Status: Fixed (was: Assigned)
Status: Verified (was: Fixed)
Bulk edit: marking stale 'fixed' bugs as 'verified' since they don't need verification at this point.

Sign in to add a comment