Vanadium
Vanadium copied to clipboard
Allow users to disable "search ready omnibox"
The "search ready omnibox" presents an empty omnibox when selected, rather than the url of the page currently rendered. To edit the url of the current page, the edit button on the toolbar below must be pressed. While this is likely great at encouraging users to search, it is frustrates me when browsing a website that uses the url as part of its user interface. If it is considered within the scope of this project, I am willing to take a shot at implementing a toggle to disable this behavior.
This is already implemented in Bromite via https://github.com/bromite/bromite/blob/93.0.4577.83/build/patches/Restore-Search-Ready-Omnibox-flag.patch
@csagan5 Thanks for the heads up. I would have no problem cherry-picking your patch, but from my understanding GrapheneOS does not want to include code licensed under GPL v3.0. I have not yet read your patch so that if needed I can implement this functionality without violating your copyright. If I am missing something, please let me know.
@Zoraver this is the patch description:
Subject: Restore Search Ready Omnibox flag
Revert "Cleanup Search Ready Omnibox flag since it has launched" This reverts commit ae458edcc8422d0815d0e82261e71fe10d7d6fc2.
Disable search-ready omnibox by default
Since it is a revert I do not think there is much to copyright under GPLv3 there; the only "original" part would be disabling it by default, and that is 3 lines of code.
@csagan5 Alright, thanks. I will give your patch a try once my vanilla build of Vanadium finishes compiling.
@thestinger Would you like the "search ready omnibox" to be enabled or disabled by default?
@Zoraver if you want to improve further this patch, you could try to figure out why word suggestions are disabled while typing in the address bar (in case you can also reproduce that with Vanadium)
@csagan5 As far as I can tell, keyboard-provided word suggestions are disabled in the omnibox in Vanadium both before and after your patch is applied; it does not seems to affect this behavior. If I were bothered by this (I'm not), I would address it in a separate patch.