1. 24 Dec, 2020 1 commit
  2. 12 Jan, 2021 1 commit
  3. 06 Dec, 2020 1 commit
    • Marco Bonardo's avatar
      Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and... · 9883c22d
      Marco Bonardo authored
      Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw, a=RyanVM
      
      Fix a race condition with Korean IME, where it may submit delayed text after
      Enter has been handled. The patch delays events if composition is still ongoing
      and avoids using the selected element or the last resultForValue if it's not
      yet complete by the time we submit the text.
      Unfortunately this cannot be tested automatically in mochitests because it
      depends on a native behavior of the IME that synthesize methods can't reproduce.
      
      Additionally this fixes Bug 1679697 by ensuring Search Mode is not dismissed
      by IME and the urlbar value is proper when confirming Tab-to-search.
      This part comes with tests.
      
      Differential Revision: https://phabricator.services.mozilla.com/D98768
      9883c22d
  4. 07 Dec, 2020 1 commit
    • Drew Willcoxon's avatar
      Bug 1678765 - Fix broken "Search with" action text for heuristic results that... · 14225c10
      Drew Willcoxon authored
      Bug 1678765 - Fix broken "Search with" action text for heuristic results that are restyled to look like search results. r=harry
      
      This was a little harder than it seemed like it should be because we show/hide
      the title separator in two places, in `UrlbarView.updateRow` and in the CSS.
      This patch gets rid of the show/hide in `updateRow`, so now we show/hide only in
      the CSS. The decision to show/hide in `updateRow` was based on whether the
      result has action text (`actionSetter`) or is a URL (`setURL`). We already had a
      `has-url` attribute that corresponds directly to `setURL`, so adding a similar
      `has-action` attribute that corresponds to `actionSetter` lets us show/hide only
      in the CSS.
      
      The second part of this patch is to actually fix the bug. For that, the existing
      `show-action-text` attribute does part of what we want in the CSS: It forces the
      action to be shown when a one-off is selected and there's no selected row. In
      addition to that, we need to show the action when both a restyled search and a
      one-off are selected, so this adds a new `restyled-search` attribute. We need
      both attributes because we do not want to show the action for a restyled search
      when some other row plus a one-off are selected (to match the current behavior).
      
      Depends on D97843
      
      Differential Revision: https://phabricator.services.mozilla.com/D98429
      14225c10
  5. 13 Nov, 2020 1 commit
  6. 06 Dec, 2020 1 commit
    • Marco Bonardo's avatar
      Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and... · 19e9e7b3
      Marco Bonardo authored
      Bug 1673669 - Fix Address Bar IME composition interaction with Search Mode and the Event Bufferer. r=adw
      
      Fix a race condition with Korean IME, where it may submit delayed text after
      Enter has been handled. The patch delays events if composition is still ongoing
      and avoids using the selected element or the last resultForValue if it's not
      yet complete by the time we submit the text.
      Unfortunately this cannot be tested automatically in mochitests because it
      depends on a native behavior of the IME that synthesize methods can't reproduce.
      
      Additionally this fixes Bug 1679697 by ensuring Search Mode is not dismissed
      by IME and the urlbar value is proper when confirming Tab-to-search.
      This part comes with tests.
      
      Differential Revision: https://phabricator.services.mozilla.com/D98768
      19e9e7b3
  7. 04 Dec, 2020 2 commits
    • Razvan Maries's avatar
      Backed out changeset a507222dac63 (bug 1678765) for perma failures on... · ee021779
      Razvan Maries authored
      Backed out changeset a507222dac63 (bug 1678765) for perma failures on browser_oneOffs_searchSuggestions.js. CLOSED TREE
      ee021779
    • Drew Willcoxon's avatar
      Bug 1678765 - Fix broken "Search with" action text for heuristic results that... · c33bf2e7
      Drew Willcoxon authored
      Bug 1678765 - Fix broken "Search with" action text for heuristic results that are restyled to look like search results. r=harry
      
      This was a little harder than it seemed like it should be because we show/hide
      the title separator in two places, in `UrlbarView.updateRow` and in the CSS.
      This patch gets rid of the show/hide in `updateRow`, so now we show/hide only in
      the CSS. The decision to show/hide in `updateRow` was based on whether the
      result has action text (`actionSetter`) or is a URL (`setURL`). We already had a
      `has-url` attribute that corresponds directly to `setURL`, so adding a similar
      `has-action` attribute that corresponds to `actionSetter` lets us show/hide only
      in the CSS.
      
      The second part of this patch is to actually fix the bug. For that, the existing
      `show-action-text` attribute does what we want in the CSS; the only problem is
      that we currently set it only when there's no selected row, but we need to also
      set it when there's no selected row but a one-off is selected. We have a similar
      block -- the one with a comment about restyling the heuristic to look like a
      search result -- so I removed the block that currently sets/removes the
      attribute and moved the set/removal there. I also renamed the attribute
      `restyled-search` to better semantically describe what's happening, but if you
      disagree I can restore the old name.
      
      Depends on D97843
      
      Differential Revision: https://phabricator.services.mozilla.com/D98429
      c33bf2e7
  8. 05 Nov, 2020 1 commit
  9. 16 Oct, 2020 2 commits
  10. 15 Oct, 2020 4 commits
  11. 14 Oct, 2020 2 commits
    • Harry Twyford's avatar
      Bug 1647929 - Announce tab-to-search results to screen readers. r=Jamie,mak,fluent-reviewers,flod · 83c008cc
      Harry Twyford authored
      This is a pretty simple implementation of the approach discussed in the bug. When a tab-to-search result is shown, we announce it to screen readers. We keep track of which engines are announced to be sure we don't keep announcing the same engine as the user types.
      
      This approach is maybe slightly crude, but I didn't find a working elegant approach. One approach I considered is checking for tab-to-search results in the loop in UrlbarView._updateResults. After the loop is finished, if we found a tab-to-search result, we go back and change the aria-label on the action text of the prior result to something like "Visit, or press Tab to search with { $engine }. This didn't work because we don't read action text for the heuristic result as the user types. This is presumbably to avoid disrupting the user as they type. This is what my patch does regardless, however... Since Jamie was skeptical about whether we should announce this at all, I put this behaviour behind a default-true pref, browser.urlbar.tabToSearch.accessibility.announceResults.
      
      Differential Revision: https://phabricator.services.mozilla.com/D93451
      83c008cc
    • Harry Twyford's avatar
  12. 07 Oct, 2020 2 commits
    • Harry Twyford's avatar
      Bug 1668389 - Only set #urlbar[open] if we are sure there will be either results or one-offs. r=mak · a576962a
      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
    • Harry Twyford's avatar
  13. 05 Oct, 2020 1 commit
  14. 30 Sep, 2020 1 commit
    • Harry Twyford's avatar
      Bug 1647923 - Add UrlbarProviderTabToSearch. r=adw,fluent-reviewers · 17135ee6
      Harry Twyford authored
      This patch adds tab-to-search results, partially reusing the existing code in `UrlbarProviderAutofill._matchSearchEngineDomain`. Tests are included. Telemetry is included in a child revision.
      
      This patch doesn't add the "Search <engine name> directly from the address bar." action text. Our current action text code l10n is in a .properties file and I thought adding branching translation logic in UrlbarView would be a mess. I think Marco might be converting that .properties file to Fluent in bug 1658629. If he is, I'll rebase my patch on his and add the new action text it in this patch. If he isn't, I'll file a follow-up for converting that .properties file and adding the tab-to-search action text, which we can address before preffing `update2.tabToComplete` on. Either way, I think this is ready for a first-round review.
      
      This patch is based on D91076 and D91077. It doesn't have any functional dependency, but there are some conflicts, especially in the added telemetry.
      
      Differential Revision: https://phabricator.services.mozilla.com/D91468
      17135ee6
  15. 29 Sep, 2020 1 commit
  16. 02 Dec, 2020 1 commit
    • Drew Willcoxon's avatar
      Bug 1678155 - Restyle all heuristic result types when a one-off is... · 72ff93fc
      Drew Willcoxon authored
      Bug 1678155 - Restyle all heuristic result types when a one-off is selected/search mode is previewed. r=harry
      
      We currently restyle URL heuristic results when a one-off is selected/search
      mode is previewed, but afaict we should restyle all types. In the case of this
      bug, the heuristic is a search result. I ended up rewriting most of
      browser_oneOffs_heuristicRestyle.js to check various result types (URL, search,
      and keyword) and both Alt-arrowing and non-Alt-arrowing down to the one-offs in
      case that makes a difference.
      
      This fixes part of bug 1678765, the part where we do the wrong thing when a
      restyled keyword result is picked. It doesn't fix the visual part where the
      action text is flush against the title text.
      
      This also fixes a small error in `UrlbarView._on_SelectedOneOffButtonChanged`
      where we were using `result.payload.title` when restyling heuristics, but
      `result.title` is the correct property.
      
      Depends on D97376
      
      Differential Revision: https://phabricator.services.mozilla.com/D97843
      72ff93fc
  17. 20 Nov, 2020 1 commit
  18. 03 Nov, 2020 2 commits
  19. 30 Oct, 2020 1 commit
  20. 28 Oct, 2020 1 commit
  21. 23 Sep, 2020 1 commit
  22. 16 Sep, 2020 1 commit
    • Drew Willcoxon's avatar
      Bug 1665292 - Clear the view's selected result and... · 08b6f031
      Drew Willcoxon authored
      Bug 1665292 - Clear the view's selected result and UrlbarInput._resultForCurrentValue when the view is cleared. r=harry
      
      First, `UrlbarView.clear` needs to null the selected element. Second, setting
      the selected element to null needs to also null
      `UrlbarInput._resultForCurrentValue`. `UrlbarView._selectElement` does call
      `input.setValueFromResult`, which sets `_resultForCurrentValue` -- but not if
      the `updateInput` arg is false. So I added a new
      `UrlbarInput.setResultForCurrentValue` method so `_selectElement` can set it. At
      first I tried unconditionally calling `input.setValueFromResult`, but a bunch of
      tests failed. I looked into it, but it's complicated, so I gave up and added
      this new method.
      
      This also makes some other changes that I'll comment on inline.
      
      Differential Revision: https://phabricator.services.mozilla.com/D90360
      08b6f031
  23. 13 Aug, 2020 1 commit
    • Drew Willcoxon's avatar
      Bug 1657918 - Don't add a heuristic result for empty searches in local search... · e2ab883d
      Drew Willcoxon authored
      Bug 1657918 - Don't add a heuristic result for empty searches in local search modes, and modify the view to allow it to stay open when empty. r=harry
      
      This excludes the heuristic for empty searches when in search mode. I haven't
      heard back from Verdi yet about excluding it for all searches in search mode. We
      can add that in a follow-up if necessary.
      
      Since we're now excluding the heuristic but we want the view to remain open,
      it's possible for the view to be empty while it's open. I had to make some
      changes to allow that to happen. There are three cases I want to call out:
      
      1. When the search string is empty, the view shows top sites. If you then enter
         search mode and the resulting search doesn't return any results, we
         previously closed the view. This patch keeps it open. An example of this
         scenario is when you don't have any bookmarks and you click the bookmarks
         one-off.
      2. When the urlbar isn't focused, it's in search mode, the input is empty, and
         the search didn't return any results, then focusing the urlbar didn't do
         anything previously. This patch auto-opens the view.
      3. When the input contains a single char and it's in search mode, deleting the
         char previously closed the view if the empty search didn't return any
         results. This patch keeps the view open.
      
      When the view is empty, we also need to hide the one-offs' top border that
      usually separates them from the results. Otherwise there are two separator lines
      right next to each other, the one above the one-offs and the one at the bottom
      edge of the input. I don't think there's any CSS selector that will let us
      easily do this due to the DOM structure, so I added a new `noresults` attribute
      on the view for this.
      
      I had to call `context.searchString.trim()` to tell whether the search string is
      empty. Since we do that in a bunch of places, I added
      `context.trimmedSearchString`, and a lot of this patch is replacing those `trim`
      calls.
      
      Differential Revision: https://phabricator.services.mozilla.com/D86908
      e2ab883d
  24. 12 Aug, 2020 1 commit
  25. 24 Oct, 2020 2 commits
    • Harry Twyford's avatar
      Bug 1667766 - Part 2 - Restyle URL heuristic results as search results when... · abd4222f
      Harry Twyford authored
      Bug 1667766 - Part 2 - Restyle URL heuristic results as search results when cycling through one-offs. r=adw
      
      This patch replaces the heuristic's icon, title, and action text when cycling through the one-offs. One problem is that the underlying result is still of RESULT_TYPE.URL, so picking it would visit its underlying URL. One way to get around this would be to create a new search UrlbarResult and swap it with the heuristic result, or change all the properties of the UrlbarResult so it becomes a search result. These approaches were discussed in review and rejected because they break the design of the QuantumBar. Having the URL result navigate to a SERP when picked would also require a lot of flags and conditionals throughout our navigation logic, which isn't ideal. I settled on promoting search mode when one of these restyled results is picked. I admit that this is a bit of a strange interaction, given that something that looks like a search heuristic result behaves like a keywordoffer, but I think its preferable to us navigating to a URL the user cannot see in the UI. As discussed in review, this result can only be picked by clicking on it. The chance of a user clicking the heuristic result while arrowing through the one-offs is exceedingly slim, so it seems like a decent compromise between UX and engineering effort. It also means selecting the restyled result with click and Enter does the same thing, so it's not completely out of nowhere.
      
      I checked a11y with this patch applied and things are mostly unchanged from a screen reader perspective. Currently, typing the string "moz", alt+arrowing to the first one-off, then selecting it will create announcements like: "m", "o", "z", "Selection replaced. Google (@google), button", "Selection replaced. moz, Search with Google, edit text". The same annoucements are made with this patch applied. Pressing down arrow (not alt) will announce the second result. Arrowing back up to the heuristic will announce the original autofill result, because the original autofill result has been swapped back in. I'll ping Jamie in the bug once this patch is mature.
      
      Differential Revision: https://phabricator.services.mozilla.com/D94338
      abd4222f
    • Harry Twyford's avatar
      Bug 1667766 - Part 1 - Refactor UrlbarView._on_SelectedOneOffButtonChange and... · 629710dc
      Harry Twyford authored
      Bug 1667766 - Part 1 - Refactor UrlbarView._on_SelectedOneOffButtonChange and fix one-off selection papercuts. r=adw
      
      This patch fixes two issues:
      
      1. When a history result was autofilled, cycling through the engine one-offs would not change its icon (as expected) and cycling through the local one-offs would change its icon, but only to the history icon. This was because UrlbarView._iconForSearchResult was only checking for the result source and wasn't checking that the result was of search type as well. For consistency, we no longer change the icon when local one-offs are selected (we will change it once we figure out a way to change it for engine one-offs as well). I also renamed this method to _iconForResult to prep for Part 2 of this patch.
      
      2. Typing a string, alt+arrowing through the one-offs, then pressing Enter flickers the heuristic result. This is because the one-off button is deselected, so we restore the original heuristic result. However, the search mode query also fires at the same time and quickly replaces the heuristic result. I added a check to not restore the original heuristic result in this case, eliminating the flicker.
      
      This patch also refactors UrlbarView._on_SelectedOneOffButtonChanged. Previously, the main loop bailed early if a local one-off was selected, thus treating local one-offs as if they were very different from engine one-offs. This new flow handles both local and engine one-offs over the course of the same loop. I think it's a bit easier to read and understand.
      
      Differential Revision: https://phabricator.services.mozilla.com/D94637
      629710dc
  26. 23 Jul, 2020 1 commit
  27. 05 Aug, 2020 1 commit
  28. 28 Jul, 2020 3 commits
  29. 27 Jul, 2020 1 commit
    • Drew Willcoxon's avatar
      Bug 1654439 - Part 2: Factor out some urlbar-specific things from... · b9137c31
      Drew Willcoxon authored
      Bug 1654439 - Part 2: Factor out some urlbar-specific things from SearchOneOffs into UrlbarSearchOneOffs. r=harry
      
      The base class retains the `popup` property, and now the `view` property is
      entirely in the subclass. I defined some new methods so that the subclass can
      easily customize behavior for a view that's not a popup. I used the name "view"
      in these method names to refer to a generic view/panel. I didn't rename `popup`
      `view` because the base class still assumes that `popup` is a `menupopup`.
      
      We could/should probably get rid of the "compact" concept and instead specialize
      the behavior even further in the subclass, but for simplicity's sake I left that
      for now.
      
      Depends on D84784
      
      Differential Revision: https://phabricator.services.mozilla.com/D84785
      b9137c31