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

VERIFIED FIXED in Firefox 44

Status

()

--
minor
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: cesarinik, Assigned: Gijs)

Tracking

32 Branch
mozilla44
x86_64
Mac OS X
Points:
---
Bug Flags:
firefox-backlog +
in-testsuite ?

Firefox Tracking Flags

(firefox44 verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
Severity: normal → trivial
Hardware: x86 → x86_64

Updated

4 years ago
Severity: trivial → minor
Component: Untriaged → Search
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
Flags: needinfo?(cesarinik)
(Reporter)

Comment 2

4 years ago
Not the search box of a search engine, but the Search box to find something inside the text of the page (cmd + F)
Flags: needinfo?(cesarinik)
(Reporter)

Comment 3

4 years ago
the problem occurs in Safe Mode too.
Component: Search → Find Toolbar
Product: Firefox → Toolkit
Summary: Returns to the last letter in the search box when switching between 2 applications. → The last letter backspaced reappears in the find box when switching between applications
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

4 years ago
UPDATE: This also happens when switching between tabs in the same firefox window.
(Assignee)

Updated

4 years ago
Flags: qe-verify+
Flags: in-testsuite?
Flags: firefox-backlog+
(Reporter)

Comment 5

4 years ago
Any news?
Bug is still unresolved.
(Assignee)

Comment 6

4 years ago
Mike, do you have cycles to investigate?
Flags: needinfo?(mdeboer)
(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.
(Reporter)

Comment 8

3 years ago
version 40.0.3, this bug is still there.
(Assignee)

Comment 9

3 years ago
Created attachment 8675876 [details]
MozReview Request: Bug 1071631 - fix findbar re-filling in last character, r?mikedeboer

Bug 1071631 - fix findbar re-filling in last character, r?mikedeboer
Attachment #8675876 - Flags: review?(mdeboer)
(Assignee)

Comment 10

3 years ago
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?) ;-)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(mdeboer)
(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 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/
Attachment #8675876 - Flags: review?(mdeboer) → review+
(Assignee)

Comment 13

3 years ago
(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. :-)
(Assignee)

Comment 14

3 years ago
Tests pass locally. For luck:

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

Comment 16

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/3a9921a0dbc7
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
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.
Status: RESOLVED → VERIFIED
status-firefox44: fixed → verified
Flags: qe-verify+
QA Contact: cornel.ionce
You need to log in before you can comment on or make changes to this bug.