* In nsAutoCompleteController, the logic that determines whether the new search is a prefix of the old search is only done in HandleText, i.e., on input, not when the value is set programmatically.
* That logic is a lot more complex in nsAutoCompleteController.
* nsAutoCompleteController autofills in one case where quantumbar doesn't: when completing the "placeholder" string before starting a new search and waiting for the async results (thereby preventing flicker).
* Some nsAutoCompleteController state gets reset each time the awesomebar is focused (see calls to attachController() in the autocomplete binding, which sets the controller's input, which calls ResetInternalState()). That state is important in regard to autofill and the placeholder string. If it's not reset, then the autofill of one search will incorrectly affect the autofill of a later search.
Differential Revision: https://phabricator.services.mozilla.com/D22306
--HG--
rename : browser/components/urlbar/tests/browser/browser_UrlbarInput_autofill.js => browser/components/urlbar/tests/browser/browser_autoFill_caretNotAtEnd.js
extra : moz-landing-system : lando
Just set the RemoteType in the options object argument, instead of
doubling up the information.
Differential Revision: https://phabricator.services.mozilla.com/D23250
--HG--
extra : moz-landing-system : lando
This fixes 2 problems causing overrides (with SHIFT/ALT/CTRL) to stick longer than expected:
1. The event bufferer may delay keydown, keyup could then happen before it
2. On some platforms holding a key generates multiple events, so there's no match in number of keydown/keyup
Differential Revision: https://phabricator.services.mozilla.com/D21665
--HG--
extra : moz-landing-system : lando
The timer cancelling in UnifiedComplete.js seems to make the tests more stable with QuantumBar for some reason. Without it, some of the sub-tests would tend to time out. This might be better once we can implement a proper waitForResult() that doesn't have to wait for the entire search to be complete.
Differential Revision: https://phabricator.services.mozilla.com/D21006
--HG--
extra : moz-landing-system : lando
The main behavior changes are:
1) We no longer create a new Window when doing document.open(). We use the
same Window but remove all the event listeners on it and on the existing DOM
tree before removing the document's existing kids.
2) We no longer create a new session history entry. The existing one always
gets replaced instead.
3) We now support document.open on documents that are not in a Window.
The reasons for the various test changes are as follows:
The change to browser_modifiedclick_inherit_principal.js is because we no
longer set the docshell to a wyciwyg URL when document.open() happens and the
test was depending on that to terminate.
browser_wyciwyg_urlbarCopying.js is being removed because it's trying to test
wyciwyg URIs, which no longer exist.
The changes in docshell/test/navigation are because document.open() no longer
affects session history. One of the tests was testing the interactions there
and is being removed; another is being repurposed to just test that
document.open() does not affect history.length.
The change to test_x-frame-options.html is because document.open() now removes
event listeners on the window, which it didn't use to do (and in the specific
case in this test reused the existing inner too, so the listener was still
around in practice). The new behavior matches other browsers.
The removal of test_bug172261.html is because document.open() no longer affects
session history, so you can't go back across it or forward to the "opened"
state, so the situation that test is trying to test no longer exists.
The changes to test_bug255820.html are because reloading a document after
document.open() will now just load the URL of the document that was the entry
document for the open() call, not reload the written content. So there's not
much point testing reload behavior, and in this test it was just reloading the
toplevel test file inside the frames.
The change to test_bug346659.html is because now we no longer create a new
Window on document.open().
The change to test_bug1232829.html is because document.open() (implicit in this
test) no longer adds history entries, so the back() was just leaving the test
page instead of going back across the document.open(). The test is a
crashtest in practice, so might still be testing something useful about how
document.open() interacts with animations.
The change to test_bug715739.html is because the URL of the document after
document.open() is now the URL of the entry document, not a wyciwyg URL, so
reload() has different behavior than it used to.
The change to test_bug329869.html is because now when we go back we're
reloading the original document we had, not doing a wyciwyg load, and the
security info now doesn't include the untrusted script.
The changes to the wpt expectations are removing a bunch of expected failures
now that we pass those tests and disabling some tests that are fundamentally
racy and hence fail randomly. The latter all have github issues filed for the
test problem.
The change to testing/web-platform/tests/common/object-association.js is fixing
tests that were not matching the spec (and were failing in other browsers).
The change to parser-uses-registry-of-owner-document.html is fixing tests that
were not matching the spec (and were failing in other browsers).
The change to document-write.tentative.html is because the test was buggy: it
was using the same iframe element for all its tests and racing loads from some
tests against API calls from other tests, etc. It's a wonder it ever managed
to pass, independent of these patches (and in fact it doesn't pass according to
wpt.fyi data, even in Firefox).
The changes in html/browsers/history/the-history-interface are because
document.open() no longer adds history entries. The test was failing in all
other browsers for the same reason.
The changes in html/browsers/history/the-location-interface are because
reloading a document.open()-created thing now loads the URL of the page that
was the entry document for the open() call. The test was failing in all other
browsers.
The change to reload_document_open_write.html is because we now reload the url
of the document that entered the script that called open() when we reload, not
the written content. Other browsers were failing this test too; Gecko with
the old document.open implementation was the only one that passed.
The change to http-refresh.py is to fix a test bug: it was not returning a
Content-Type header, so we were putting up helper app dialogs, etc.
The change to test_ext_contentscript.js is because we no create a new global
for document.open() calls. Kris Maglione OKed this part.
Differential Revision: https://phabricator.services.mozilla.com/D17323
--HG--
extra : moz-landing-system : lando
This doesn't enable the rightClick option for telemetry reporting as that is complicated to support, see bug 1528250.
Differential Revision: https://phabricator.services.mozilla.com/D19951
--HG--
extra : moz-landing-system : lando
Any time we QI to nsIFrameLoaderOwner in tests, we're really accessing
a MozFrameLoader. We don't need to be doing that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19727
--HG--
extra : moz-landing-system : lando
There are a few potential places to do this:
(1) UrlbarProviderUnifiedComplete, when it creates results
(2) UrlbarResult.payloadAndSimpleHighlights(), which UrlbarProviderUnifiedComplete calls when it creates results (and presumably other providers would call it, too)
(3) UrlbarResult._titleAndHighlights(), when it figures out what to return as the title
It's hard to do it in (3) because in that location, we don't know the user's search string, so we don't know what to highlight. (1) is possible, but it would probably be nice for other providers and all result types to benefit from this? So I chose (2), and also because UrlbarResult.payloadAndSimpleHighlights() is just an easy place to do it since UrlbarProviderUnifiedComplete calls it for each result it creates.
The actual code to get the domain is copied from autocomplete.xml more or less.
Differential Revision: https://phabricator.services.mozilla.com/D18642
--HG--
extra : moz-landing-system : lando
We should replace the context.autofillValue property with a result.autofill property. When the view selects results, it already notifies the input about it by calling input.setValueFromResult(). So we can modify setValueFromResult to check for the presence of result.autofill and thereby get autofill "for free".
result.autofill is an object: { value, selectionStart, selectionEnd }
This is going to help me implement bug 1521702.
One potentially cool thing about doing autofill this way is that any result can now trigger autofill, not only the heuristic result, and do it easily. Of course the user isn't typing when they select a non-heuristic result, so it's probably not fair to call that "autofill", but the result can trigger the selection aspect of autofill. As one example, that might be interesting for search suggestions: Type "foo", key down to the "foobar" suggestion, and the "bar" substring is automatically selected.
Differential Revision: https://phabricator.services.mozilla.com/D18618
--HG--
extra : moz-landing-system : lando
We should replace the context.autofillValue property with a result.autofill property. When the view selects results, it already notifies the input about it by calling input.setValueFromResult(). So we can modify setValueFromResult to check for the presence of result.autofill and thereby get autofill "for free". (The one place where the view doesn't call input.setValueFromResult() when a result is selected is when it selects the preselected result, so this patch adds that.)
result.autofill is an object: { value, selectionStart, selectionEnd }
This is going to help me implement bug 1521702.
One potentially cool thing about doing autofill this way is that any result can now trigger autofill, not only the heuristic result, and do it easily. Of course the user isn't typing when they select a non-heuristic result, so it's probably not fair to call that "autofill", but the result can trigger the selection aspect of autofill. As one example, that might be interesting for search suggestions: Type "foo", key down to the "foobar" suggestion, and the "bar" substring is automatically selected.
Differential Revision: https://phabricator.services.mozilla.com/D18618
--HG--
extra : moz-landing-system : lando
This is a rollup of all the patches that have landed on the cedar project branch:
891252fdd0
Bug 1492475 - Part 1: Migrate most, if not all nsSearchService consumers to use async APIs. r=florian
79b2eb2367
Bug 1492475 - Part 2: Move nsIBrowserSearchService.idl to toolkit/components/search/nsISearchService.idl and update references. r=florian
a947d3cdf0
Bug 1492475 - Part 3: The search service init() method should simply return a Promise. r=florian
c1e172dfac
Bug 1492475 - Part 4: Remove the synchronous initialization flow. r=florian
cd41189eac
Bug 1492475 - Part 5: Since async initialization of the search service now is implicit behavior, remove the distinctive verbiage used internally. r=florian
2ae7189dfa
Bug 1492475 - Part 6: Update the cache build task to work with an actual Promise and re-initialize only once at the same time - all to fix race conditions here. r=florian
c8ee92973f
Bug 1492475 - Part 7: Make the region fetch not block the init flow, to ensure it's as fast as possible. r=florian
c44e674e16
Bug 1492475 - Part 8: Introduce an init flag, which can only be used privately, that allows to explicitly skip waiting for the region check process to complete. r=florian
6c79eaf1d3
Bug 1492475 - Part 9: Update unit tests to stop using 'currentEngine', in favor of 'defaultEngine'. r=Standard8
21b3aa17ee
Bug 1492475 - Part 10: Update unit tests to be fully aware of the new, async signatures of the search service API and remove sync init flow tests. r=mkaply,florian
ce5ba69019
Bug 1492475 - Part 11: Repair incorrect usage of the `identifier` property of nsISearchEngine instances. r=florian
fd177a7994
Bug 1518543 - Fix up the Android (Fennec) nsISearchService shim to work with the new asynchronous API. r=florian
3653d8ee22
Bug 1523708 - Change the search service interaction in the show-heartbeat action to use the new async API. r=florian
Differential Revision: https://phabricator.services.mozilla.com/D18355
--HG--
rename : netwerk/base/nsIBrowserSearchService.idl => toolkit/components/search/nsISearchService.idl
extra : moz-landing-system : lando
This starts porting other tests to work with QuantumBar and starts expanding UrlbarTestUtils.jsm with more helper functions.
For the tests, I'm generally using replacing with UrlbarTestUtils except for promiseAutocompleteResultPopup/promiseSearchComplete. These functions feel like they need a more in-depth change (bug 1522902), but probably not until we can remove the old bar.
browser_autocomplete_a11y_label.js and browser_autocomplete_autoselect.js are partially ported, but won't run on QuantumBar yet due to missing functionality.
Depends on D18262
Differential Revision: https://phabricator.services.mozilla.com/D18338
--HG--
rename : browser/components/urlbar/tests/legacy/browser_action_searchengine.js => browser/components/urlbar/tests/browser/browser_action_searchengine.js
rename : browser/components/urlbar/tests/legacy/browser_action_searchengine_alias.js => browser/components/urlbar/tests/browser/browser_action_searchengine_alias.js
rename : browser/components/urlbar/tests/legacy/browser_autocomplete_edit_completed.js => browser/components/urlbar/tests/browser/browser_autocomplete_edit_completed.js
rename : browser/components/urlbar/tests/legacy/browser_new_tab_urlbar_reset.js => browser/components/urlbar/tests/browser/browser_new_tab_urlbar_reset.js
rename : browser/components/urlbar/tests/legacy/browser_urlbar_remove_match.js => browser/components/urlbar/tests/browser/browser_urlbar_remove_match.js
extra : moz-landing-system : lando
browser_UrlbarInput_unit.js leaks the empty.xul window every time I run it on a debug build. I narrowed down the leak to the objects/properties that this patch nulls out after closing the window. Simply cleaning up these properties in a register-cleanup function isn't enough to stop the leak. It happens after the test creates either one of its two UrlbarInputs. Cleaning up the properties after each UrlbarInput is created doesn't stop the leak either. Cleaning up the properties *plus* opening a new window for each UrlbarInput does stop the leak though, so that's what this patch does.
However, the leakcheck test still logs `UNEXPECTED-FAIL leakcheck: default 1392 bytes leaked` at the end, which it does currently without this patch. That doesn't cause the test to fail though, unlike the leaks reported in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D18154
--HG--
extra : moz-landing-system : lando
