User text entry in location / address bar gets replaced with first autocomplete/history/search hit when switching tabs and back

VERIFIED FIXED in Firefox 68

Status

()

defect
P1
normal
VERIFIED FIXED
3 months ago
2 months ago

People

(Reporter: Gijs, Assigned: dao)

Tracking

(Blocks 1 bug, Regression, {dataloss, regression})

68 Branch
Firefox 69
Points:
2
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox67 unaffected, firefox67.0.1 unaffected, firefox68+ verified, firefox69 verified)

Details

Attachments

(1 attachment)

Looks like similar things happen with any substring, e.g. after typing just "foo" in a tab and switching away and back to the tab, suddenly the URL bar has "football" (which I assume is a search hit or something).

Keywords: dataloss
Summary: Bookmark keyword entry in location / address bar gets replaced with first history hit when switching tab → User text entry in location / address bar gets replaced with first autocomplete/history/search hit when switching tabs and back

I'm having difficulties reproducing this bug, Drew?

Flags: needinfo?(adw)

(In reply to :Gijs (he/him) from comment #1)

Looks like similar things happen with any substring, e.g. after typing just
"foo" in a tab and switching away and back to the tab, suddenly the URL bar
has "football" (which I assume is a search hit or something).

I can't reproduce it either, and I don't recall it happening in my normal use. When it happens, could you check to see whether the replacement string is one of the results in the popup, like one of the search suggestions? That would be interesting if so. Since neither Marco nor I can reproduce it, do you think you could narrow down the STR any further? Does it happen all the time?

Flags: needinfo?(adw) → needinfo?(gijskruitbosch+bugs)

STR:

  1. clean profile on current beta or nightly
  2. open prefs/options, turn off "Ctrl+Tab cycles through tabs in recently used order" (this being off used to be the default and existing profiles were never changed)
  3. open a new tab
  4. type in "foo"
  5. accel-shift-tab to go back to the previous tab
  6. accel-tab to go to the next tab

ER:
location bar says "foo"

AR:
location bar says "food poisoning" or some other search result

Flags: needinfo?(gijskruitbosch+bugs)

(The STR in comment #4 reproduce 100% of the time for me. Tested on macOS, if that matters.)

On Windows I cannot reproduce yet, so maybe it's a Mac thing? I may try later.

oh wait nevermind, I CAN reproduce. I suspect we are actually handling CTRL + TAB as TAB and moving the selection in the urlbar view (setting value)

Points: --- → 2
Priority: -- → P1
Regressed by: 1548031

or better, we are handling SHIFT+TAB, moving the selection backwards, that means select the last search suggestion if search suggestions are after results.

I assume we don't intend to let quantumbar ride with 68 at this point?

This was regressed by bug 1501623 (found via mozregression with quantumbar forced to true)

Flags: needinfo?(dao+bmo)
Regressed by: 1501623

(In reply to Marco Bonardo [::mak] from comment #8)

or better, we are handling SHIFT+TAB, moving the selection backwards, that means select the last search suggestion if search suggestions are after results.

Note that TAB has the same effect for me, ie if I have just 2 tabs open, both about:newtab, empty location bar in both, then in one of them type "foo" and then hit ctrl+tab, the bug occurs.

(In reply to :Gijs (he/him) from comment #10)

(In reply to Marco Bonardo [::mak] from comment #8)

or better, we are handling SHIFT+TAB, moving the selection backwards, that means select the last search suggestion if search suggestions are after results.

Note that TAB has the same effect for me, ie if I have just 2 tabs open, both about:newtab, empty location bar in both, then in one of them type "foo" and then hit ctrl+tab, the bug occurs.

Oh, but I get different values as a result, so that corroborates your hypothesis - we're picking the first suggestion if using accel-tab, and the last suggestion when using accel-shift-tab...

yes, we are not considering CTRL in practice and handling the keypress without it.

(In reply to :Gijs (he/him) from comment #9)

I assume we don't intend to let quantumbar ride with 68 at this point?

Let's be real careful with these kind of statements, since you're proposing to unship a whole feature on this bug only. This may be a considerably serious bug, but I suspect the fix to be trivial. I therefore think it's relatively premature to consider the whole feature to be flawed/ at risk at this point.

I'm requesting tracking for this bug, because we intend to ship QuantumBar with Firefox 68.

(In reply to Mike de Boer [:mikedeboer] from comment #13)

(In reply to :Gijs (he/him) from comment #9)

I assume we don't intend to let quantumbar ride with 68 at this point?

Let's be real careful with these kind of statements, since you're proposing to unship a whole feature on this bug only. This may be a considerably serious bug, but I suspect the fix to be trivial. I therefore think it's relatively premature to consider the whole feature to be flawed/ at risk at this point.

I didn't intend to propose anything - that's why I asked! - it's just that the last time I checked, quantumbar's pref was ifdef'd on EARLY_BETA_OR_EARLIER, indicating it wasn't set to ride the train. This seems to have changed literally yesterday, and wasn't widely announced (yet), so sorry for not getting the memo... :-\

:D We're good - apology for assuming you intended otherwise - we indeed didn't announce our plans to ship with 68 widely! I'm quite confident we'll be able to fix this in the most reasonable timeframe. Thanks!

Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Iteration: --- → 69.3 - Jun 10 - 23
Flags: needinfo?(dao+bmo)
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fc447daeb26f
Don't handle Tab key when Ctrl or Alt are pressed. r=Gijs
Flags: qe-verify+
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69

Comment on attachment 9070775 [details]
Bug 1556774 - Don't handle Tab key when Ctrl or Alt are pressed. r=Standard8

Beta/Release Uplift Approval Request

  • User impact if declined: see comment 4
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: see comment 4. (I want to look into writing an automated test but think we should uplift this in the meantime.)
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): trivial fix ported from the legacy urlbar code
  • String changes made/needed:
Attachment #9070775 - Flags: approval-mozilla-beta?

Comment on attachment 9070775 [details]
Bug 1556774 - Don't handle Tab key when Ctrl or Alt are pressed. r=Standard8

quantumbar fix for 68.0b10

Attachment #9070775 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Build ID 20190613095633
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:69.0) Gecko/20100101 Firefox/69.0

Verified as fixed on the latest Nightly (v69.0a1) on macOS 10.13.

Build ID 20190613141208
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Firefox/68.0

Verified as fixed on the latest Beta build (v68.b10) on macOS 10.13.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.