1152517 - Recipient autocomplete wrongly considers last mouse-hovered contact from results dropdown "selected" and then uses that unintended, random recipient upon blur (via Tab, Enter, or when moving to subject or body)

Status: RESOLVED FIXED

(Toolkit :: Autocomplete, defect, P1)

Description

[Joris Debonnet]

Attachment: Screenshot showing the issue

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

1. Have a contact list that contains multiple people with names starting with "Ma"
2. Compose a new message
3. Click inside the "To:" field (then leave the mouse there)
4. Type "Ma"
5. Several names will appear in a dropdown list, and the first one will already be pre-filled in. 
6. The first one is the one I wanted, handy! I guess I'm ready to write my message. 
7. I move the mouse down and click inside the body.


Actual results:

In the process of moving the mouse down, another name in the dropdown list may be higlighted, despite the first name still being filled in to the To: field. 

Then if you press return or tab, everything's fine, the first name stays selected. But if you CLICK anywhere outside the To: field, it will use the highlighted name from the dropdown field, overwriting the first name that was there before! 


Expected results:

It is very counter-intuitive if the field gets filled in with something else than what you last saw there. People may accidently send messages to the wrong person, because they didn't notice it changed. (It has happened multiple times already to a friend of mine.)

Took a while to explain,.. but the screenshot summarizes the problem!

Comment 1

[Thomas D. (:thomas8)]

Indeed, just hovering mouse across the dropdown results will come with a sticky selection which "selects" entries which have just accidentally been hovered. That bogus selection will then apply for blur actions like tab, click-outside etc.

I think this comes from the autocomplete widget, and I recall same bug for FF.

Bad stuff.

Comment 2

[Magnus Melin [:mkmelin]]

(think there's an older duplicate, but I can't find it)

Comment 4

[Thomas D. (:thomas8)]

TB swapping intended address to random addresses is very bad behaviour which violates privacy; it's also dataloss of the deliberately chosen recipient. -> critical.

Comment 7

[Thomas D. (:thomas8)]

This bug has better description, STR, and screenshot -> dupetome

Comment 8

[Thomas D. (:thomas8)]

(In reply to Kent James (:rkent) from comment Bug 745664 comment 20)
> It would be great if people interested in QA had some standard BMO searches
> they do, and then advocate for particular bugs that they think are important.

Per Kent's comment, I hereby advocate for this particular bug to be fixed as a matter of urgency, both for TB 31 ESR and TB 38. Messing with recipients without user's consent is one of the worst things a mailer can do. And user has no reason to double-check, because simply clicking away from a field must never change the field contents (definitely not to something which was not even seen in the field before leaving it).

(In reply to Thomas D. from comment #4)
> TB swapping intended address to random addresses is very bad behaviour which
> violates privacy; it's also dataloss of the deliberately chosen recipient.
> -> critical.

Comment 9

[Kevin Fisher]

I am having this same issue in version 31.6.0 .. if I start typing an 'H' to have it select a contact starting with H from my address book, Thunderbird will display 4 names of which only 1 actually starts with H at all. The other 3 do not start with H. As I only have 1 person starting with H in my address book, there should be only 1 displayed .. not the 4 (which includes the 3 that do not start with H at all). As a result .. it will select usually the WRONG contact if you click on the body of the window to begin sending your email .. and the likelihood of sending the email to the WRONG contact is very very real. This is just a recent issue and I have just about sent the email to the wrong contact several times. This is pretty serious .. and embarrassing should content be sent to the wrong person. Btw .. if you type 3 letters in the TO field, it does seem to select the right contact. This however needs to be fixed .. as only contacts starting with H should be displayed at all from the get go.

Comment 10

[Kevin Fisher]

Re my above comment .... I have found why it is how it is. It is cause a Wildcard Autocomplete is now used. Honestly .. I would like the OPTION to select names based on the beginning of the contact name ONLY. Can this be configured in Thunderbird ? I really hate the wildcard search for contacts. For now I am using an old version of Thunderbird. I know I have just about sent emails to the wrong person because of the wild card search as it is now. Poor poor design .. it should be an option to allow / disallow the wildcard search in my opinion. As far as I know .. Outlook for example does not use the wildcard search for just this reason, way too many opportunities to send the email to the wrong person based on the wildcard search rather than a 'beginning only search' as was previously in Thunderbird.

Comment 11

[Thomas D. (:thomas8)]

OT - this comment is not relevant for this bug

(In reply to Kevin Fisher from comment #10)
> Re my above comment .... I have found why it is how it is. It is cause a
> Wildcard Autocomplete is now used. Honestly .. I would like the OPTION to
> select names based on the beginning of the contact name ONLY. Can this be
> configured in Thunderbird ?

Currently not, but we're trying to make it configurable, e.g. as a by-product of bug 118624.

> I really hate the wildcard search for contacts.

Others (like me) love it, because it finally finds what unexpectedly wasn't found before :)
I think it's reasonable to expect that searching for "doe" should find "[e-mail]"...

> For now I am using an old version of Thunderbird. I know I have just about
> sent emails to the wrong person because of the wild card search as it is
> now. Poor poor design .. it should be an option to allow / disallow the
> wildcard search in my opinion. As far as I know .. Outlook for example does
> not use the wildcard search for just this reason, way too many opportunities
> to send the email to the wrong person based on the wildcard search rather
> than a 'beginning only search' as was previously in Thunderbird.

You're mixing too many things. If your preferred contact is not at the top of the list, it's because your search word is not specific enough (1 character is not really unique...), or the sorting algorithm is not good enough (true, we need bug 382415), or both. FF location bar also has wildcard search yet they are very good at guessing right at the users intention because they have a much smarter algorithm of frecency, which also considers the relation between actual search input and user-chosen result. As in the [e-mail] example above, results that aren't relevant for you can be relevant for others. Search failures (not finding expected results) are worse than having a few false positives; frecency should fix that by intelligent sorting. False positives cannot be avoided with whatever algorithm we choose; so they are not a problem as such as long as TB doesn't unexpectedly mess around with your deliberate choice behind your back (this bug). Even "startsWith" results would come with a list of people you're NOT looking for, so you'd still have "many opportunities to send the email to the wrong person", and it's your choice and responsibility to pick the right one (assisted by frecency sorting algorithm, which is where we are not good enough yet).

Btw, have you tried using two search words which will rapidly narrow down your results list? You can search for "jo do" to find "[e-mail]" or "John Doe". The more unique your combination of search words, the fewer results...

Implementing an option to choose between "contains" and "startsWith" algorithm is much harder than it sounds:
- we currently have a dual search design whith an initial url-based c++ search, whose result set is then narrowed down by a hard-coded javascript search (for speed gains which need to be rechecked, as the c++ search is said to be faster; so I wonder if we could have a fast c++ implementation that reduces the result set?).
- switching between "contains" and "startsWith" becomes much harder as soon as we allow users to fully customize their search: what if you're using both types of search for different contacts fields?
So IMO the better road is to let users fully customize their search (or even the sorting algorithm as was suggested in bug 1067681), ideally even with a full UI similar to the advanced search UIs we have. But we're not there yet, and manpower is VERY limited...

The issue of this bug is that after you explicitly selected one recipient from the results list, TB might later swap that against a completely random other contact of the results list, depending on how you move your mouse and then click somewhere else. Now THAT's a bad bug because it's dataloss(y) and a massive violation of your privacy. Which is completely unrelated to your issue of just *seeing* results that you don't want to see. So this entire discussion is actually off-topic (OT) for this bug.

Comment 12

[Thomas D. (:thomas8)]

Kevin, good news for you, for TB 38, Bug 1134986 will change the sorting algorithm by returning more weight to popularityIndex, so your favorite contacts have a better chance of being top-listed among other results.

Comment 13

[Kevin Fisher]

It is not a problem. I have switched to Outlook from Thunderbird. I prefer the 'starts with' method, which Outlook does. I don't have any problems anymore. Honestly .. the contains is just dumb, when you do not give the user the option of opting out.

Comment 14

[Thomas D. (:thomas8)]

(In reply to Kevin Fisher from comment #13)
> It is not a problem. I have switched to Outlook from Thunderbird. I prefer
> the 'starts with' method, which Outlook does. I don't have any problems
> anymore. Honestly .. the contains is just dumb, when you do not give the
> user the option of opting out.

Try to understand the significant difference between "I prefer something else" and "it is just dumb" (which is also pretty impolite to say), especially after I have just taken time to give you an honest and detailed explanation in comment 11.

Actually, your scenario of comment 9 should work: If there's really only one person starting with "H" in your address book, it will be toplisted when you type "h". Right here where you commented, we are in the process of fixing the bug that TB might swap your choice with an unintended recipient from the results list after the fact, depending on your mouse interaction patterns. When this will be fixed, I'm failing to see your problem: You can just ignore those 3 extra results that you personally weren't looking for, and confirm the toplisted result, which is your desired result.

Comment 15

[Thomas D. (:thomas8)]

Coming from Bug 1107844 where users like Bug 1107844 Comment 61 were insisting that they still have problems even when Enter is pressed, I just discovered a really nasty variant of this bug, which is much easier to get and thus likely to be much more frequent:

1) With mouse, click into recipient field, then move mouse 1cm below recipient input (which easily happens when you just let go of your mouse as it will still move a little)

2) In recipient input field, type character like "a" which triggers multiple autocomplete results
-> results list will pop up below your mouse pointer: (*)

3) Accidentally, move mouse just a tiny little bit (perhaps your right hand is still on it while you typed with the left)
-> will cause another result from the dropdown to be highlighted (Anthony)

[A{nna <[e-mail]>}    ]   <-- Anna is toplisted/pre-selected and partially highlighted
 Alois <...>
{Anthony (*) <...>}  <-- at the same time(!) Anthony is selected (!) and highlighted
 Alma <...>

Note how this is actually a case of apparent "double focus", because there can never be two blue selections at the same time!

4) Press Tab or Enter

Actual result:

Although the toplisted result (Anna) looks very much like the currently selected option in the input field, it will be discarded and unexpectedly, the result which happens to be under the mouse pointer will be confirmed.

This is really nasty because it happens so easily and it's really cunning as user has no reason to assume that confirming Anna with Tab or Enter will change the recipient to be Anthony!!!

Critical, datalossy privacy violation - 
Must be fixed asap and backported to TB 31.x!!!

Comment 16

[frogsfarms]

Thomas,
Sorry for not noticing the differences between the bugs concerning this matter and we appreciate all the work which has been put into the program. But it is very nasty to find my mails ending up at wrong desks, which still happens with TB 38.ob3. Just hope the general problem of changing mail addresses will be solved soon. Until than I will change this PC back to TB 24.7.
Keep up the great work.

Comment 17

[tai133]

As a developer, I know there is a strong motivation to 'defend' new features even as users are complaining about them. But I try to come from a 'the customer is always right' perspective and additionally have been personally harmed by this bug and several others which have come before it on the same topic. I would strongly prefer a much 'dumber' UI that retained the address I selected instead of cleverly trying to decide for me. This problem has gone on too long through too many Thunderbird versions and needs to be suppressed immediately. At the very least we need a configuration option to turn off the cleverness.

I love Mozilla products and greatly appreciate the hours of work that go into developing them. I have used Firefox and Thunderbird since almost Day 1. I would advocate that the original concept of simple, effective applications be kept in mind and that the tendency towards 'bloat' be kept in check. I know: off-topic for this bug.

Comment 18

[jason.austin]

(In reply to tai133 from comment #17)
> As a developer, I know there is a strong motivation to 'defend' new features
> even as users are complaining about them. But I try to come from a 'the
> customer is always right' perspective and additionally have been personally
> harmed by this bug and several others which have come before it on the same
> topic. I would strongly prefer a much 'dumber' UI that retained the address
> I selected instead of cleverly trying to decide for me. This problem has
> gone on too long through too many Thunderbird versions and needs to be
> suppressed immediately. At the very least we need a configuration option to
> turn off the cleverness.
> 
> I love Mozilla products and greatly appreciate the hours of work that go
> into developing them. I have used Firefox and Thunderbird since almost Day
> 1. I would advocate that the original concept of simple, effective
> applications be kept in mind and that the tendency towards 'bloat' be kept
> in check. I know: off-topic for this bug.

I think tai133 has expressed perfectly how most of us feel.   Could we please get this fixed.

Comment 19

[Magnus Melin [:mkmelin]]

Nobody is saying it is desired behavior. It's just a question of lacking manpower. Patches welcome!

Comment 20

[Wayne Mery (:wsmwk)]

> I would advocate that the original concept of simple, effective applications be kept in mind and that the tendency towards 'bloat' be kept in check. I know: off-topic for this bug.

So there is no misunderstanding, this is NOT a shiny new feature. The familiar whipping boy of "bloat" is not available here. It's just a nasty, cranky bug. 

History - A strategic decision was made to switch to firefox's toolkit autocomplete code, for sustainability and other reasons.  The old code base lacked tests, so there was (and is) no way to measure how the replacement code behaved compared to the old code. Testing was done, but obviously not enough. But there is no going back to the old code, it has been removed from current versions including the version 38 which will ship within a few weeks. The path forward is to fix the current code base, and volunteers have worked hard to fix many auto complete issues.  

Until this is fixed (and we do want it fixed) user vigiliance is appropriate. Further comments which don't involve making a patch are distracting to those working on fixing bugs.

Comment 21

[Kent James (:rkent)]

Because this is not a new regression in Thunderbird 38, the proper tracking is to keep it visible as an important issue in Thunderbird 38 (tracking-thunderbird_esr38) but it will not block the release of thunderbird_38 (not tracking-thunderbird38).

Comment 22

[Thomas D. (:thomas8)]

There's an impressive variety of scenarios where TB reverts user's explicitly confirmed recipient and cunningly picks another unrelated recipient instead (which is dataloss and privacy violation):

Bug 1130858 - Recipient autocomplete suggestion overrides ANY manual address input if quickly entered/pasted and confirmed with Enter/Tab before autocomplete suggestions disappear

Bug 1138033 - Stubborn recipient autocomplete silently swaps recipients: Cannot compose message to valid, normal, new email address ([e-mail]/[e-mail]) if similar longer address already exists in AB ([e-mail]/[e-mail])

Bug 1152517 - Recipient autocomplete wrongly considers last mouse-hovered contact from results dropdown "selected" and then uses that unintended, random recipient upon blur (via Tab, Enter, or when moving to subject or body)

So to work around all of them, users will need to:
- Slow down when entering/confirming recipients to avoid Bug 1130858
- Put a comma even after a single recipient, or add every recipient to your AB first, to avoid Bug 1138033
- Move their mouse pointer into some safe corner of the screen before(!) entering a recipient, to avoid Bug 1152517

Easy, ain't it? :p

Comment 25

[Mark Lindemann]

Bug 1168920 also references this (original) problem.

Comment 26

[Thomas D. (:thomas8)]

Magnus, are you taking this, or can you find the right people who broke this on the toolkit??
I suppose there must be a FF or toolkit equivalent of this bug, too...
This is really nasty and happens easily in everyday scenarios like comment 15.

Comment 27

[weg_bei_bedarf]

A really HORRIBLE BUG!!! 
Due to that bug wrong recipients have got confidential information!!!!

No one expects an address to be changed by Thunderbird after clicking in the message field only because there was a previously moving of the mouse over suggested addresses (without clicking them explicitly!)

Please fix as soon as possible!

Besides: Thanks for your great work with Thunderbird!

Comment 28

[frogsfarms]

This bug is a disaster...
Just return to version 24.7.0
Everything works fine there...
Make sure you cancel "automatic update"
This bug is a disaster...

Comment 29

[Magnus Melin [:mkmelin]]

Attachment: bug1152517_autocomplete_mouse_over_selects.patch

We do handleEnter in blur so that suggested addresses always get the proper format. Now, in mousemove the popup selectedIndex is set to what you hover over. On blur we must make sure that the selected result is the one whose text matches what's filled in the autocomplete text box, not the result you happened to hover over.

Comment 30

[Nils Bruechert]

Pretty please fix this asap. Only by pure luck I avoided getting in serious trouble because of this. I sent a bunch of work emails to wrong recipients, most of them not very happy about it.

Comment 31

[von_bugzilla]

To all CC recipients who also consider this _severe_ bug as critical: 
Please vote for Importance P1 critical! Right now there are only 5 votes. 

How can you vote? Just click the link "(vote)" in the header line at the top of the page:
 Importance: 	P1 critical with 5 votes including you (vote) 

That helps the Thunderbird developers to recognize this bug as severe as ist is.

Thanks a lot!

Comment 32

[frogsfarms]

Sorry
there is no link "(vote)" in the header line at the top of the page on my PC as far as I can see????
hans

Comment 33

[von_bugzilla]

it´s not easy to find... 
but in the head section it´s in line 8:

Status: 	ASSIGNED
Whiteboard: 	[dupetome][nasty simple variant: comm...
Keywords: 	dataloss, privacy
Product: 	Thunderbird (show info)
Component: 	Message Compose Window (show other bugs) (show info)
Version: 	31
Platform: 	All All
Importance: 	P1 critical with 8 votes including you (vote) 
.....

hope that helps to find the vote-link

Comment 34

[TonyC]

Thanks for the help in finding the vote link. I would never have found it otherwise. If it helps anyone TB 31.2 seems to be free of this serious bug.

Comment 35

[K.J. Petrie]

My own bug (1178547) appears similar, differing only in the event triggering the change and that possibly mousing over the substituted address might not have occurred.

Presumably, if the list is not closed on selection (once a selection has occurred only that one entry should match the criteria since the field contents are now the full entry), there is always the possibility of some event triggering a change in the choice if it causes the list to be replayed or revisited.

This is a truly nasty bug as continuing to use TB once the existence of the bug is known would violate privacy laws in many countries, where users have a duty to protect data, including not using buggy software.

So I think it's a P1 too.

Comment 36

[Thomas D. (:thomas8)]

(In reply to von_bugzilla from comment #31)
> To all CC recipients who also consider this _severe_ bug as critical: 
> Please vote for Importance P1 critical! Right now there are only 5 votes. 

For the avoidance of doubt, votes are independent of the other importance properties. You are voting for the bug to be fixed (which in this case will probably imply that you agree with its severity/urgency). 
Priority and Severity are set exclusively by developers. Priority is already on "P1", which is the maximum. Severity is on "critical" which is also pretty much the maximum; beyond that there's only "blocker" which may not seem to match the nature of this bug and it wouldn't change much now because we're already working on a fix.

On 18th June 2015, Magnus has offered a patch to fix this bug, attachment 8624475 [details] [diff] [review], which is currently waiting for review from Marco Bonardo.

Comment 37

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Comment on attachment 8624475 [details] [diff] [review]
bug1152517_autocomplete_mouse_over_selects.patch

Review of attachment 8624475 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/content/widgets/autocomplete.xml
@@ +603,5 @@
>          if (!this._dontBlur) {
> +          if (this.forceComplete && this.mController.matchCount >= 1) {
> +            // mousemove sets selected index. Don't blindly use that selected
> +            // index in this blur handler since if the popup is open you can
> +            // easily "select" another address just by moving the mouse over it.

s/address/match/

@@ +604,5 @@
> +          if (this.forceComplete && this.mController.matchCount >= 1) {
> +            // mousemove sets selected index. Don't blindly use that selected
> +            // index in this blur handler since if the popup is open you can
> +            // easily "select" another address just by moving the mouse over it.
> +            var v = this.value.replace(/.+ >> /, "").toLowerCase();

let filledVal

@@ +605,5 @@
> +            // mousemove sets selected index. Don't blindly use that selected
> +            // index in this blur handler since if the popup is open you can
> +            // easily "select" another address just by moving the mouse over it.
> +            var v = this.value.replace(/.+ >> /, "").toLowerCase();
> +            var s = (this.popup.selectedIndex == -1) ? null :

for readability:
let selectedVal = null;
if (this.popup.selectedIndex >=0)
  selectedVal = this.mController...

@@ +608,5 @@
> +            var v = this.value.replace(/.+ >> /, "").toLowerCase();
> +            var s = (this.popup.selectedIndex == -1) ? null :
> +              this.mController.getFinalCompleteValueAt(
> +                this.popup.selectedIndex).toLowerCase();
> +            if (v != s) {

I'd prefer if you'd move both .toLowerCase() here in the condition

@@ +610,5 @@
> +              this.mController.getFinalCompleteValueAt(
> +                this.popup.selectedIndex).toLowerCase();
> +            if (v != s) {
> +              for (var i = 0; i < this.mController.matchCount; i++) {
> +                if (this.mController.getFinalCompleteValueAt(i).toLowerCase() == v) {

local temp var for readability:
let matchVal

Comment 39

[K.J. Petrie]

If you can show how clicking send can blur a field which didn't have focus I will accept it is a duplicate. otherwise I can't.

Comment 40

[Magnus Melin [:mkmelin]]

Attachment: bug1152517_autocomplete_mouse_over_selects.patch

Addressing review comments.

Comment 41

[Magnus Melin [:mkmelin]]

Ok try run at https://treeherder.mozilla.org/#/jobs?repo=try&revision=8f3228e9db6f

Comment 43

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Comment on attachment 8632582 [details] [diff] [review]
bug1152517_autocomplete_mouse_over_selects.patch

Review of attachment 8632582 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/content/widgets/autocomplete.xml
@@ +618,5 @@
> +              selectedVal = this.mController.getFinalCompleteValueAt(
> +                this.popup.selectedIndex);
> +            }
> +            if (selectedVal && filledVal != selectedVal.toLowerCase()) {
> +              for (var i = 0; i < this.mController.matchCount; i++) {

s/var/let/

Comment 45

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c36bb974792d

Comment 46

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c36bb974792d

Comment 47

[Thomas D. (:thomas8)]

Comment on attachment 8632582 [details] [diff] [review]
bug1152517_autocomplete_mouse_over_selects.patch

[Approval Request Comment]
Regression caused by (bug #): autocomplete migration (?)
User impact if declined: Massive breach of privacy, sending messages to wrong recipients in everyday non-special scenarios
Testing completed (on c-c, etc.): 
Risk to taking this patch (and alternatives if risky): Probably low (?)

Bug reports on this issue are on the increase as it occurs so easily. It's a nasty and cunning bug. This should be uplifted as high as possible and be fixed whereever we can fix it. Thanks.

Comment 48

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #47)
> status-firefox42: fixed → ---

I didn't touch that firefox flag but it got lost when changing those other flags. I can't set it back to what it was. Someone with the powers should try, but please ensure TB flags are kept, too.

Comment 49

[Magnus Melin [:mkmelin]]

Comment on attachment 8632582 [details] [diff] [review]
bug1152517_autocomplete_mouse_over_selects.patch

The last 31 we will ever do was already done.


Please hold on with approval requests until we have baked on trunk for a while. Also, this is a mozilla-central patch.

Comment 50

[Jorg K (CEST = GMT+2)]

The bug was in the wrong product, so status-firefox42 was not available. Now it is.

If you want inclusion in TB, you need to create another bug à la bug 1173261 as a duplicate of this one, so:
Bug xxx - Take "Bug 1152517 - Recipient autocomplete wrongly considers last mouse-hovered contact ..." in TB 38.x

In there, you can request uplift into comm-release. It makes no sense to uplift into comm-aurora and comm-beta since only comm-release has its own M-C branch (based on mozilla38) the release is built on. So with luck, you can get this into TB 38.x.

It will be in TB 42 automatically, if you want it in TB 41, you need to request M-C Aurora uplift here.

No way to get it into TB 40 (beta). Forget about TB 39 anyway. BTW: The same is true for bug 1130858.

Comment 53

[Jorg K (CEST = GMT+2)]

Inclusion into TB 38.x: See bug 1187519.

Comment 56

[Kent James (:rkent)]

http://hg.mozilla.org/releases/mozilla-esr38/rev/326a41e65147 for THUNDERBIRD_38_VERBRANCH

Comment 57

[sebastien.ramage]

it's supposed to be fixed ? But the bug is still in Thunderbird 38.2.0...

Comment 58

[Jorg K (CEST = GMT+2)]

Which part? The "mouse hover" part is fixed in TB 38.2.
For <tab> and <enter> see bug 1192739.

Comment 59

[sebastien.ramage]

Oh ok, I meant the <tab> and <enter> bug.

Comment 60

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+2) from comment #58)
> Which part? The "mouse hover" part is fixed in TB 38.2.
> For <tab> and <enter> see bug 1192739.

Both parts can involve "mouse hover".
We only fixed the "mouse hover" + "mouse click elsewhere" scenario.
We did not yet fix the "mouse hover" + tab/enter scenario (bug 1192739).