-
Harry Twyford authored
This was more difficult to solve than I expected. The main issue is that the `[open]` attribute on `#urlbar` wasn't accurate when the view was "open" but there were no results or one-offs, so it was in fact closed. This broke a few style rules. This bug can also be reached when the user has no engines and clears the search string while in search mode. This includes pressing Accel+K when typing a search string while not in search mode. The relationship between the UrlbarView and the one-offs is complex and depends on a lot of listeners and async calls made in synchronous contexts. Furthermore, most of the UrlbarView open/close code is synchronous, but checking the number of engines (to determine if the one-offs will open) is an async operation. These factors make it difficult for the view to discern any state about the one-offs and plan accordingly. First I tried adding a [oneoff] attribute to .urlbarView, set asynchronously when the one-offs are built. Then I changed CSS rules to check ``` .urlbarView:not([noresults]), .urlbarView[oneoffs] ``` instead of just `#urlbar[open]`. This approach would've required changing a bunch of CSS from the simple `#urlbar[open]` to the more complicated CSS above, which was not good for code readability. Also it would keep `[open]` in a weird useless state where it couldn't really be trusted. This would've caused other styling problems. I settled on adding a `.then` call around the affected UrlbarView opening. The view opens only if we are sure that we will have either results or one-offs, so we can once again trust the `[open]` parameter. This approach has its drawbacks. Mainly, it's a more JavaScript-heavy solution so it's possibly slow. Thankfully, it's something that can be easily cached. Differential Revision: https://phabricator.services.mozilla.com/D92526
a576962a