Window leak on Android in contenteditable
Reported by
kmans...@gmail.com,
Oct 31 2017
|
||||
Issue description
Steps to reproduce the problem:
1. contenteditable in a WebView
2. select text, WebView shows selection handles
3. close the window (activity)
4. >>>> Android logcat complains about a window leak
5. Can be reproduced with Gmail app on its compose screen
The logcat message:
android.view.WindowLeaked: Activity com.google.android.gm.ComposeActivityGmail has leaked window android.widget.PopupWindow$PopupDecorView{6443c80 V.E...... ........ 0,0-132,66} that was originally added here
at android.view.ViewRootImpl.<init>(ViewRootImpl.java:368)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:299)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:85)
at android.widget.PopupWindow.invokePopup(PopupWindow.java:1258)
at android.widget.PopupWindow.showAtLocation(PopupWindow.java:1032)
at android.widget.PopupWindow.showAtLocation(PopupWindow.java:995)
at org.chromium.android_webview.PopupTouchHandleDrawable.show(PopupTouchHandleDrawable.java:239)
at org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(Native Method)
at org.chromium.base.SystemMessageHandler.handleMessage(SystemMessageHandler.java:9)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5417)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
What is the expected behavior?
No window leak, no complains in logcat
What went wrong?
Android logcat complains about a leaked window
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 63.0.3239.20 Channel: beta
OS Version: 6.0
Flash Version: N/A
,
Oct 31 2017
Assigning to the owner. Almost similar issue reported for Samsung Galaxy S4 : Issue 725895 kmansoft@ could you please provide the device info.
,
Oct 31 2017
is ondetachedfromwindow called in that case? if not, not sure this is actually fixable
,
Nov 1 2017
Re: #2 I saw it on a Nexus 5 (6.0 official: M4B30Z). Same thing on a Nexus 5x (8.1 beta: OPP5.170921.005).
,
Nov 1 2017
Issue 725895 is not related. It should be safe to rely on onDetachedFromWindow in this case - the onAttachedToWindow and onDetachedFromWindow calls are always supposed to "balance". The only case you don't get the call is if the view was never attached to the window in the first place, which won't be the case if the user has already interacted with it to get the selection popups. Are we just not doing this at all right now, or is something weirder going on?
,
Nov 1 2017
,
Jan 10 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by rlanday@chromium.org
, Oct 31 2017