Make LocalNTPUITest use the real local NTP, rather than local_ntp_browsertest.html |
||||
Issue descriptionLocalNTPUITest.FakeboxRedirectsToOmnibox should use the real local NTP rather than local_ntp_browsertest.html, which is basically a third-party NTP that implements similar functionality. (Which is also worth testing, but separately.) I had a first attempt at this in https://crrev.com/c/789884 which promptly got reverted (https://crrev.com/c/803534) for causing massive flakiness on Windows (Mac and Linux were fine). Dashboard link for future reference: https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=interactive_ui_tests&tests=LocalNTPUITest There seem to be two possible failure modes: ../../chrome/browser/ui/search/local_ntp_uitest.cc(98): error: Expected: OMNIBOX_FOCUS_INVISIBLE Which is: 2 To be equal to: omnibox()->model()->focus_state() Which is: 0 ../../chrome/browser/ui/search/local_ntp_uitest.cc(104): error: Value of: result Actual: false Expected: true and ../../chrome/browser/ui/search/local_ntp_uitest.cc(58): error: Expected: OMNIBOX_FOCUS_NONE Which is: 0 To be equal to: omnibox()->model()->focus_state() Which is: 2
,
Dec 6 2017
,
Jan 18 2018
New attempt is at https://crrev.com/c/817565, but still getting the same errors. Interestingly, the flakiness dashboard currently shows a few instances of the same failure on Linux and Windows, *without* that CL. So it looks like the CL isn't actually the cause of the problems, it just makes them worse/more visible somehow.
,
Mar 1 2018
,
Sep 24
Kyle - we should review this as part of the Local NTP work.
,
Sep 25
I think we should hold off on this until we finally experiment with removing the fakebox. There are a number of open bugs that are obsolete once the fakebox-omnibox interaction no longer exists. |
||||
►
Sign in to add a comment |
||||
Comment 1 by bugdroid1@chromium.org
, Dec 6 2017