1. 01 May, 2019 6 commits
  2. 29 Apr, 2019 1 commit
  3. 01 May, 2019 7 commits
  4. 18 Apr, 2019 1 commit
    • Barret Rennie's avatar
      Bug 1510569 - Ensure we still have a listener after calling delayed progress... · 5449ef60
      Barret Rennie authored
      Bug 1510569 - Ensure we still have a listener after calling delayed progress listeners in nsBrowserStatusFilter r=Ehsan
      
      The nsBrowserStatusFilter flushes pending status and progress updates when an
      OnStateChange event for a STATE_STOP state is triggered. This may run its
      OnProgressChange and OnStatusChange listeners, which may in turn run arbitrary
      JavaScript or even remove the web progress listener from the filter. When this
      happens, we will continue to call the OnStateChange event handler on a listener
      that is now a nullptr, causing a crash.
      
      We now explicitly check that we still have a web progress listener before
      continuing and have renamed the ProcessTimeout function to a more descriptive
      name (CallDelayedProgressListeners) that indicates what it actually does.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28123
      
      --HG--
      extra : moz-landing-system : lando
      5449ef60
  5. 01 May, 2019 2 commits
    • Ashley Hauck's avatar
      Bug 1547915 - Correctly handle private identifiers with escapes. r=jorendorff · e0e53baa
      Ashley Hauck authored
      Differential Revision: https://phabricator.services.mozilla.com/D29392
      
      --HG--
      extra : moz-landing-system : lando
      e0e53baa
    • Drew Willcoxon's avatar
      Bug 1539804 - Quantumbar: Re-enable browser_urlbarStopSearchOnSelection.js and... · 70e0b1ac
      Drew Willcoxon authored
      Bug 1539804 - Quantumbar: Re-enable browser_urlbarStopSearchOnSelection.js and fix a couple of related problems. r=mak
      
      This test uncovered a couple of problems:
      
      (1) UrlbarController.handleKeyNavigation relies on event.defaultPrevented to tell whether the one-offs handled the key event. That's a problem when combined with deferring the down arrow key.
      
      handleKeyNavigation is called twice in that case. The first time, the event is deferred (so executeAction = false), and handleKeyNavigation calls event.preventDefault. The second time, the event is being replayed, but defaultPrevented is true from the previous call regardless of whether the one-offs actually handled the event.
      
      So handleKeyNavigation always returns early because it thinks the one-offs always handled the event, so it never properly replays down arrow keys.
      
      (2) UrlbarProviderUnifiedComplete's query promise is never resolved when the query is canceled. That's a problem in general of course but I tripped over it in this test because I need to check results after the query is canceled, and the test ended up hanging since UrlbarTestUtils waits for the query to finish in order to get its results.
      
      It's not a problem in UnifiedComplete itself per se because of course awesomebar uses UnifiedComplete too, and it doesn't have this problem. The difference is that nsAutoCompleteController::StopSearch calls input->OnSearchComplete() (via PostSearchCleanup): https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/toolkit/components/autocomplete/nsAutoCompleteController.cpp#1433
      
      Quantumbar's UnifiedComplete provider is missing that behavior, so this patch adds it by resolving its query promise when the query is canceled.
      
      Differential Revision: https://phabricator.services.mozilla.com/D29300
      
      --HG--
      extra : moz-landing-system : lando
      70e0b1ac
  6. 30 Apr, 2019 1 commit
  7. 01 May, 2019 6 commits
  8. 29 Apr, 2019 1 commit
  9. 01 May, 2019 15 commits