1071631 - The last letter backspaced reappears in the find box when switching between applications

Status: VERIFIED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Riccardo Cesarini]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140917194002

Steps to reproduce:

Open Firefox and open in a web page.
Open (for example) Google Chrome and go to another web page.
In Firefox 32.0.1 for MAC (but in 32 and 31 too) , go to the search box and write what you want to search.
Once you've found it, delete everything with backspace.
Switch between browser with cmd + tab.
Switch again (back on Firefox)



Actual results:

You'll see that the last letter that was canceled before switching browser (the first letter of the word you searched before) reappeared.


Expected results:

The search box should be empty.

Comment 1

[Matthew N. [:MattN]]

Just to double check, do you mean the Search box that allows you to search on search engines or do you mean the find toolbar that lets you search for text in a page?

Can you try reproduce in safe mode which will temporarily disable any extensions? I suspect it's caused by one of them.

https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode

Thanks

Comment 2

[Riccardo Cesarini]

Not the search box of a search engine, but the Search box to find something inside the text of the page (cmd + F)

Comment 3

[Riccardo Cesarini]

the problem occurs in Safe Mode too.

Comment 4

[Riccardo Cesarini]

UPDATE: This also happens when switching between tabs in the same firefox window.

Comment 5

[Riccardo Cesarini]

Any news?
Bug is still unresolved.

Comment 6

[:Gijs (he/him)]

Mike, do you have cycles to investigate?

Comment 7

[Mike de Boer [:mikedeboer]]

(In reply to :Gijs Kruitbosch from comment #6)
> Mike, do you have cycles to investigate?

I wish I had! I'm leaving the n-i here, because this'll be the first non-Hello bug I'll take on.

Comment 8

[Riccardo Cesarini]

version 40.0.3, this bug is still there.

Comment 9

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1071631 - fix findbar re-filling in last character, r?mikedeboer

Bug 1071631 - fix findbar re-filling in last character, r?mikedeboer

Comment 10

[:Gijs (he/him)]

This is a little hacky, but I didn't want to write an empty string to the find clipboard (I don't know if OSX even likes that).

Anyway, the essential problem is that the last non-empty string gets chucked into the find clipboard, and then if the text in the clipboard doesn't match on focus, it assumes you want that text changed.

TBH, I find the whole thing weird. What about the following workflow:

1) open tab 1, search for "gijs"
2) open tab 2, search for "mike"
3) switch back to tab 1

now "gijs" gets replaced with "mike". That is normally an improvement, I'm sure, but I don't know that it makes sense in this case... (ie why are we overriding user input with the find clipboard?) ;-)

Comment 11

[Mike de Boer [:mikedeboer]]

(In reply to :Gijs Kruitbosch from comment #10)
> TBH, I find the whole thing weird. What about the following workflow:
> 
> 1) open tab 1, search for "gijs"
> 2) open tab 2, search for "mike"
> 3) switch back to tab 1
> 
> now "gijs" gets replaced with "mike". That is normally an improvement, I'm
> sure, but I don't know that it makes sense in this case... (ie why are we
> overriding user input with the find clipboard?) ;-)

Myeah, the most important thing here is that we do whatever the user expects from an OSX app. Apple defined the rules for us in this case. And I believe this is just the way it works on OSX, even though there are very few apps out there that sport 'tabs' as their primary UI element. Except for other browsers, of course :)

Comment 12

[Mike de Boer [:mikedeboer]]

Comment on attachment 8675876 [details]
MozReview Request: Bug 1071631 - fix findbar re-filling in last character, r?mikedeboer

https://reviewboard.mozilla.org/r/22473/#review20327

Thanks so much for taing this bug! I think this would work OK, even though it looks indeed a bit like a hack.

r=me with comments adressed and with an all-green try run ;-)

::: toolkit/content/widgets/findbar.xml:84
(Diff revision 1)
> +        }

This is likely to have an effect on the findbar mochitest-chrome tests... did you run them to check if they still pass?

::: toolkit/content/widgets/findbar.xml:1115
(Diff revision 1)
> +            this._findFiled._hadValue = true;

s/findFiled/findField/

Comment 13

[:Gijs (he/him)]

(In reply to Mike de Boer [:mikedeboer] from comment #11)
> (In reply to :Gijs Kruitbosch from comment #10)
> > TBH, I find the whole thing weird. What about the following workflow:
> > 
> > 1) open tab 1, search for "gijs"
> > 2) open tab 2, search for "mike"
> > 3) switch back to tab 1
> > 
> > now "gijs" gets replaced with "mike". That is normally an improvement, I'm
> > sure, but I don't know that it makes sense in this case... (ie why are we
> > overriding user input with the find clipboard?) ;-)
> 
> Myeah, the most important thing here is that we do whatever the user expects
> from an OSX app. Apple defined the rules for us in this case. And I believe
> this is just the way it works on OSX, even though there are very few apps
> out there that sport 'tabs' as their primary UI element. Except for other
> browsers, of course :)

Hm, I just checked Safari. Their behaviour is weird - they keep text in the find bar from the previously-selected tab (so "mike" sticks around going back to tab 1), but they don't update the findbar's results, and so the page remains dimmed with "gijs" highlighted. Bonkers. :-)

Comment 14

[:Gijs (he/him)]

Tests pass locally. For luck:

remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=84ad5e7e4766

Comment 15

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/3a9921a0dbc7

Comment 16

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3a9921a0dbc7

Comment 17

[Cornel Ionce [:noni] [Hubs QA]]

Reproduced the initial issue on Mac OS X 10.8.5 with the 2015-10-20 Aurora build.

Confirming the fix on latest 44.0a2 DevEdition, build ID: 20151118004041.