You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feedback: No keyboard on Sentry default feedback form #5331
Relevant conversation with claude code about this:
So Sentry never set the FLAG_ALT_FOCUSABLE_IM flag? It was set by AlertDialog (which Sentry feedback extends) and then never changed by sentry?
⏺ Yes, exactly.
The sequence we traced:
SentryUserFeedbackDialog extends AlertDialog.
When show() is called, Dialog.dispatchOnCreate() fires, which calls SentryUserFeedbackDialog.onCreate(). The first line of that is super.onCreate(savedInstanceState) → runs AlertDialog.onCreate().
AlertDialog.onCreate() invokes AlertController.installContent(), which installs AlertDialog's default layout (title + message + OK/Cancel buttons — no EditTexts). As part of that pipeline, the framework's auto-detection runs, sees "no text editors in the content," and sets FLAG_ALT_FOCUSABLE_IM on the window.
Control returns to SentryUserFeedbackDialog.onCreate(), which then calls setContentView(R.layout.sentry_dialog_user_feedback) — swapping in Sentry's layout, which does contain three EditTexts. But setContentView just replaces the view hierarchy; it does not re-run the IME-flag detection.
Sentry's code touches nothing else on the window — no addFlags, no clearFlags, no setSoftInputMode. We grep-confirmed this earlier by searching the Sentry source for any flag manipulation and finding none.
So the flag is inherited "stuck on" from step 3 and survives through step 4. The dialog ships to the window manager with FLAG_ALT_FOCUSABLE_IM set and behaves as if its content needs no IME.
Our fix clears the flag explicitly — both before show() and again in OnShowListener (belt-and-suspenders, since the flag's exact lifecycle inside AlertDialog isn't formally documented) — and then we call showSoftInput ourselves on the focused EditText so the IME comes up regardless of any lingering state.
Whether this is technically a bug in Sentry or in AlertDialog is debatable: AlertDialog's auto-detection assumes setContentView happens before onCreate, which isn't the Sentry flow. Either side could fix it — Sentry by clearing the flag after their setContentView, or AlertDialog by re-detecting on content changes. Neither does, so we patch it from the app.
Activity
linear-code commentedon Apr 23, 2026
JAVA-487
ereise205 commentedon Apr 23, 2026
Relevant conversation with claude code about this:
So Sentry never set the FLAG_ALT_FOCUSABLE_IM flag? It was set by AlertDialog (which Sentry feedback extends) and then never changed by sentry?
⏺ Yes, exactly.
The sequence we traced:
SentryUserFeedbackDialog extends AlertDialog.
When show() is called, Dialog.dispatchOnCreate() fires, which calls SentryUserFeedbackDialog.onCreate(). The first line of that is super.onCreate(savedInstanceState) → runs AlertDialog.onCreate().
AlertDialog.onCreate() invokes AlertController.installContent(), which installs AlertDialog's default layout (title + message + OK/Cancel buttons — no EditTexts). As part of that pipeline, the framework's auto-detection runs, sees "no text editors in the content," and sets FLAG_ALT_FOCUSABLE_IM on the window.
Control returns to SentryUserFeedbackDialog.onCreate(), which then calls setContentView(R.layout.sentry_dialog_user_feedback) — swapping in Sentry's layout, which does contain three EditTexts. But setContentView just replaces the view hierarchy; it does not re-run the IME-flag detection.
Sentry's code touches nothing else on the window — no addFlags, no clearFlags, no setSoftInputMode. We grep-confirmed this earlier by searching the Sentry source for any flag manipulation and finding none.
So the flag is inherited "stuck on" from step 3 and survives through step 4. The dialog ships to the window manager with FLAG_ALT_FOCUSABLE_IM set and behaves as if its content needs no IME.
Our fix clears the flag explicitly — both before show() and again in OnShowListener (belt-and-suspenders, since the flag's exact lifecycle inside AlertDialog isn't formally documented) — and then we call showSoftInput ourselves on the focused EditText so the IME comes up regardless of any lingering state.
Whether this is technically a bug in Sentry or in AlertDialog is debatable: AlertDialog's auto-detection assumes setContentView happens before onCreate, which isn't the Sentry flow. Either side could fix it — Sentry by clearing the flag after their setContentView, or AlertDialog by re-detecting on content changes. Neither does, so we patch it from the app.
fix(feedback): Improve shake detection sensitivity (#5366)
github-actions commentedon May 6, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #5359, which was included in the 8.41.0 release.