Branches: default Platforms: OS Report: http://mozmill-daily.blargon7.com/#/functional/report/ff9854eb4c0740912386985627ef7de7 Affected tests: TEST: testAwesomeBar/testCheckItemHighlight.js MODULE: testCheckItemHighlight MESSAGE: Only one autocompleted result is underlined - '0' should equal '1' show more TEST: /testAwesomeBar/testSuggestBookmarks.js MODULE: testStarInAutocomplete MESSAGE: The auto-complete result is a bookmark - 'priority-search' should contain 'bookmark' show more TEST: /testAwesomeBar/testSuggestHistory.js MODULE: testSuggestHistoryAndBookmarks MESSAGE: Expected to be one visible result in the autocomplete list - '4' should equal '1' show more TEST: /testAwesomeBar/testSwitchToTab.js MODULE: testSwitchToTab MESSAGE: Active tab url should equal the page url show more --- mc pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=70be728521e3&tochange=a9b43778f0c2 (nothing stands out here)
Cosmin, please prepare a skip patch.
status-firefox34: --- → affected
Keywords: regression, regressionwindow-wanted
Created attachment 8470799 [details] [diff] [review] patch v1.0 Hi ANdrei, here is the skip patch.
Attachment #8470799 - Flags: review?(andrei.eftimie)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8c4a1b3a2a8b&tochange=86afc8441856 Regressor looks to be bug 1050683. Lets see if I can get a minimized testcase quickly. Marco, do you know how bug 1050683 could interact with our tests here?
Comment on attachment 8470799 [details] [diff] [review] patch v1.0 Review of attachment 8470799 [details] [diff] [review]: ----------------------------------------------------------------- Thanks Cosmin! Disabled: https://hg.mozilla.org/qa/mozmill-tests/rev/cc32cbd05b32 (default)
Created attachment 8470804 [details] google.jpg This is weird, for all (well, at least 3/4) tests, when we type in the AwesomeBar instead of our desired string, we get something else. In this case: "grants >> google.com" with the second part selected.
Created attachment 8470810 [details] testcase.js Here's a testcase. We type into the urlbar, after a few hundred ms ">> google.com" gets appended. Digging into mozmill's sendKeys / type methods to see if slowing down the process actually makes a difference.
In mozmill with `sendKeys` we iterate over the string characters and issue an event for each of them. If I put a sleep greater than 25ms on each iteration the test passes, I don't get ">> google.com" appended in the urlbar. With 20ms I get either result. Unfortunately I can't type _this_ fast, so I'm not able to manually reproduce the issue.
So this ">> example.com" isn't expected? I noticed that behavior starting 1 or 2 weeks ago and thought this is probably intended, although I couldn't find anything about it. If this wasn't intended this is not a regression, but the bug is only uncovered by that patch. (Note: I've been using browser.urlbar.delay=0, which probably was already enough to get this bug to show up)
(In reply to Johannes Pfrang [:johnp] from comment #8) > So this ">> example.com" isn't expected? I noticed that behavior starting 1 > or 2 weeks ago and thought this is probably intended, although I couldn't > find anything about it. I can't see any possible reason I would like something like that appended in my urlbar. I don't see it doing anything useful either... > If this wasn't intended this is not a regression, > but the bug is only uncovered by that patch. (Note: I've been using > browser.urlbar.delay=0, which probably was already enough to get this bug to > show up) Thanks for the preference tip. I'll check it out. If this is indeed a couple of weeks old and can be seen with this pref, I'll get the correct regressor.
Indeed with `browser.urlbar.delay=0` I can reproduce this issue on older builds.
(In reply to Andrei Eftimie from comment #9) Yeah I didn't like it either, but it looked like "human-programmed-behavior" not like a bug or sth like that, so I tried to live with it. Good that you can reproduce, good luck finding the regressor. Now I'd really like the old behavior back ;)
(In reply to Andrei Eftimie from comment #5) > Created attachment 8470804 [details] > google.jpg > > This is weird, for all (well, at least 3/4) tests, when we type in the > AwesomeBar instead of our desired string, we get something else. > > In this case: "grants >> google.com" with the second part selected. this is a bug, I think I saw it today but couldn't figure out STR, likely as you said it's because manually I can't type fast enough to cause it. There must be a race condition that the tests are hitting by typing much faster than a user could. Could you please file a bug blocking UnifiedComplete about this unexpected in-the-middle completion (the >> indicates that). bug 1050683 might have caused this by the fact it ignores browser.urlbar.delay for the autoFill query.
mc pushlog for the _real_ regression (first bad build: 2014-07-25): https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a91ec42d6a9c&tochange=613e79262240 Likely that bug 1040335 is responsible for this issue as well (as we have other tests currently disabled because of the new Unified Autocomplete). I should still have those builds, should be a quick check if it indeed is.
please check if bug 1051830 solved some of these.
We will wait over the weekend before we are going to re-enable the tests. No-one of SV is around today due to a public holiday, and we don't want to risk other failures over the weekend. But thanks for fixing it Marco!!
Assignee: nobody → andrei.eftimie
Status: NEW → ASSIGNED
Indeed bug 1051830 has fixed the issues we were seeing. Backed out skip https://hg.mozilla.org/qa/mozmill-tests/rev/c86ff15d77c9 (default)
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox34: affected → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.