Closed Bug 1071631 Opened 10 years ago Closed 9 years ago

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

Categories

(Toolkit :: Find Toolbar, defect)

32 Branch
x86_64
macOS
defect
Not set
minor

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox44 --- verified

People

(Reporter: cesarinik, Assigned: Gijs)

Details

Attachments

(1 file)

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.
Severity: normal → trivial
Hardware: x86 → x86_64
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)
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)
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
UPDATE: This also happens when switching between tabs in the same firefox window.
Flags: qe-verify+
Flags: in-testsuite?
Flags: firefox-backlog+
Any news?
Bug is still unresolved.
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.
version 40.0.3, this bug is still there.
Bug 1071631 - fix findbar re-filling in last character, r?mikedeboer
Attachment #8675876 - Flags: review?(mdeboer)
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+
(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. :-)
Tests pass locally. For luck:

remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=84ad5e7e4766
https://hg.mozilla.org/mozilla-central/rev/3a9921a0dbc7
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
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
Flags: qe-verify+
QA Contact: cornel.ionce
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: