1. 24 Dec, 2020 1 commit
  2. 12 Jan, 2021 1 commit
  3. 21 Dec, 2020 2 commits
  4. 11 Dec, 2020 1 commit
  5. 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
  6. 17 Nov, 2020 1 commit
  7. 13 Nov, 2020 1 commit
  8. 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
  9. 27 Oct, 2020 1 commit
  10. 19 Oct, 2020 1 commit
  11. 16 Oct, 2020 1 commit
  12. 15 Oct, 2020 6 commits
  13. 14 Oct, 2020 1 commit
  14. 10 Oct, 2020 1 commit
  15. 29 Sep, 2020 1 commit
    • Harry Twyford's avatar
      Bug 1647923 - Add tab-to-search telemetry. r=adw · e51e1ee0
      Harry Twyford authored
      This adds tab-to-search telemetry, both for the new tabtosearch search mode entry point and for tabtosearch results in our usual Urlbar result-selection scalars. I also added a subtest in browser_urlbar_event_telemetry, but realized as I was writing it that it was not useful. We don't consider entering search more as the end of an engagement, so tab-to-search results will not appear in event telemetry. We already considered this in bug 1654680 and resolved it by adding detailed urlbar.searchmode.* scalars, so I don't consider it a blocker. I left the new subtest in since it was mostly done anyways and it can't hurt.
      
      Differential Revision: https://phabricator.services.mozilla.com/D91469
      e51e1ee0
  16. 17 Nov, 2020 1 commit
  17. 20 Nov, 2020 1 commit
  18. 18 Nov, 2020 1 commit
    • Marco Bonardo's avatar
      Bug 1676038 - Change partial tab-to-search matching to avoid autofilling... · 4b048acc
      Marco Bonardo authored
      Bug 1676038 - Change partial tab-to-search matching to avoid autofilling unexpected subdomains. r=adw
      
      The previous approach was autofilling partial subdomains from search engines.
      Having a search engine pointing to "developer.mozilla.org, when "moz" was typed
      we ended up autofilling "moz[illa.org]" but pointing to "developer.mozilla.org".
      Unfortunately that made impossible to actually go to "mozilla.org" by typing it.
      
      The new approach instead allows tab-to-search results to appear even if there's
      no autofill, because the provider checks autonomously the autofill threshold.
      There's a downside though, with the old approach we could return more partial
      matches, and the Muxer would pick one, depending on the autofilled host. For
      example we could return "rover.ebay.com" and match it to "eb[ay.it]".
      With the new approach we don't have an autofilled host, and fetching it would
      be expensive, we can only compare the search string with the engine's host.
      For this reason the patch also tries to partially match against the searchForm
      host, that often points to a page the user visits more often.
      
      Differential Revision: https://phabricator.services.mozilla.com/D96942
      4b048acc
  19. 04 Nov, 2020 1 commit
  20. 27 Oct, 2020 1 commit
  21. 25 Sep, 2020 2 commits
    • Harry Twyford's avatar
    • Harry Twyford's avatar
      Bug 1665076 - Call setSearchMode directly from search(), fix search mode... · 4515b744
      Harry Twyford authored
      Bug 1665076 - Call setSearchMode directly from search(), fix search mode handoff, and introduce new search mode probes. r=adw
      
      This patch calls setSearchMode directly from search(). This sets up a solution for the problem in the bug and also fixes the issue where a call to search() with a restriction token would flicker the token before it was replaced with the search mode indicator. I added new tabmenu and bookmarkmenu entry points to take advantage of this new functionality.
      
      This also fixes the issues with handoff. Besides the problem of search() recording typed for handoff, `handoff` wasn't even registered as a Telemetry probe! That was my mistake. I added a test for handoff telemetry. It was only practical to test it in PBM since it uses a different implementation than about:home that's easier to test. I wrote a lengthy comment above the subtest about why I think this is okay.
      
      Differential Revision: https://phabricator.services.mozilla.com/D91076
      4515b744
  22. 21 Aug, 2020 1 commit
  23. 17 Sep, 2020 1 commit
  24. 16 Sep, 2020 1 commit
  25. 17 Sep, 2020 1 commit
  26. 15 Sep, 2020 1 commit
  27. 16 Sep, 2020 1 commit
  28. 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
  29. 12 Aug, 2020 1 commit
  30. 08 Aug, 2020 1 commit
  31. 27 Oct, 2020 1 commit
  32. 19 Oct, 2020 2 commits