At the moment, we send inputType |= InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS when entering text into the address bar in private mode. Originally, this was because enabling keyboard suggestions there caused issues with some keyboards. This is no longer the case, however we kept this option in private mode as a workaround to try preventing keyboards from saving the user's input there. This method isn't particularly reliable, though, as some keyboards decided to ignore this flag (presumably because enough users complained about not being able to use the keyboard's suggestions in some apps - I think e.g. Chrome used TYPE_TEXT_FLAG_NO_SUGGESTIONS in its address bar for a long time, too) and also no longer really necessary now that we've got IME_FLAG_NO_PERSONALIZED_LEARNING available, which is meant specifically for things like our private browsing mode. Therefore, once more keyboards start supporting IME_FLAG_NO_PERSONALIZED_LEARNING, we should think about either - stop sending TYPE_TEXT_FLAG_NO_SUGGESTIONS at all, - or else creating a whitelist of keyboards that no longer require this workaround in our InputMethods helper class (https://dxr.mozilla.org/mozilla-central/rev/47248637eafa9a38dade8dc3aa6c4736177c8d8d/mobile/android/geckoview/src/main/java/org/mozilla/gecko/InputMethods.java). There's no need to do anything yet, though: Gboard is the only keyboard that supports this at the moment and it doesn't provide any suggestions in URL input mode anyway, no matter whether TYPE_TEXT_FLAG_NO_SUGGESTIONS is used or not. Swiftkey on the other hand has been ignoring TYPE_TEXT_FLAG_NO_SUGGESTIONS anyway, so once they start supporting IME_FLAG_NO_PERSONALIZED_LEARNING we don't need to take any action, either. We only need to do something once we get a IME_FLAG_NO_PERSONALIZED_LEARNING-compatible keyboard where using TYPE_TEXT_FLAG_NO_SUGGESTIONS in URL input mode actually makes a difference.