922040 - Find Toolbar Next button fails to select next occurrence for the first try

Status: RESOLVED DUPLICATE of bug 928619

(Toolkit :: Find Toolbar, defect)

Description

[Andrei Eftimie]

Steps:

1) Open "https://mozqa.com/data/firefox/layout/mozilla.html"
2) Open the Find Toolbar: Ctrl/Cmd + F
3) Type "community"
4) The first item should be highlighted
5) Click on the Next button

Expected results:
- the next occurrence should be highlighted

Actual results:
- the same (first) occurrence is still highlighted

Only affectes the first try, and only by using the mouse to interact with the Next button.
Pressing Enter to select the next occurrence works fine.

This reproduces on Nightly and Aurora, Windows and Linux
It works as expected on OSX

I will have a regression range shortly.

Comment 1

[Andrei Eftimie]

This has regressed in mozilla-central between the 13th and the 14th September.

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b9029b1de410&tochange=53d5e43e23cc

Will see if I can further narrow it down

Comment 2

[Andrei Eftimie]

The changeset responsible for the regression is http://hg.mozilla.org/integration/mozilla-inbound/rev/3734bebc9bfb

Tom, Mike could you please look into this?

Comment 3

[Tom S [:evilpie]]

Weird, I will take a look.

Comment 4

[Tom S [:evilpie]]

I can reproduce this, but the reason for this are still a mystery to me. I added some logging and everything looks quite reasonable:


// Entering Community:
fastFind: C
fastFind: Co
fastFind: Com
fastFind: Comm
fastFind: Commu
fastFind: Commun
fastFind: Communi
fastFind: Communit
fastFind: Community
// Pressing the next arrow
// This is some logging I added to "onFindAgainCommand"
findString: Community
findFieldValue: Community
searchString:Community
//
findAgain: false

Comment 5

[Luís Miguel [:quicksaver] (not reading bugmail)]

When you click the button, the content window is losing focus (or something) which is causing either the cursor or the current match selection to be reset somehow. Since it actually has no current match at the time it is calculating "the next match", it goes to the match that was already selected because that is in fact the next match.

To see what I mean, just change onFindAgainCommand() to a dummy function or have it return right at the top so it does nothing: when you click the next button, there will be no current match (when you hit F3 the match will stay as expected, since nothing will be done in this case). This didn't happen before.

Comment 6

[Luís Miguel [:quicksaver] (not reading bugmail)]

From what I can tell, the culprit seems to be the "blur" handler in the findbar textfield (a/toolkit/content/widgets/findbar.xml line 106), which by calling focus() on the window content seems to remove the current match selection.

My testing was very simple, I added a listener to the findbar textfield:

> bar._findField.addEventListener('blur', cancelBlur, true);

where cancelBlur:
> function(e) {
> 	if(testBlur) return;
> 	testBlur = true;
> 	e.preventDefault();
> 	e.stopPropagation();
> 	//bar.browser.finder.focusContent();
> 	testBlur = false;
> }

Inside cancelBlur(e) I preventDefault() and stopPropagation() the event (so it doesn't reach the textfield's own blur handler). Everything seems to work fine this way when I click the next button. But by adding the extra finder.focusContent() call, the original behavior happens again. testBlur is an outside variable, its checks are only so my handler doesn't also cancel its own call to finder.focusContent() which produces its own blur event in the textfield.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Bug 916536 should address this for 26.

Comment 8

[Andrei Eftimie]

I can confirm that 26 is now unaffected.

Comment 10

[Tom S [:evilpie]]

Bug 928619 should have fixed this. The patch is also on Aurora now. Can somebody verify?

Comment 11

[Luís Miguel [:quicksaver] (not reading bugmail)]

Verified working in latest Nightly. The latest Aurora build still doesn't have the patch yet apparently, but I'll try it again when it updates.

Comment 12

[Luís Miguel [:quicksaver] (not reading bugmail)]

Also confirmed working in Aurora now.

Comment 13

[Tom S [:evilpie]]

Thanks!

Comment 14

[bhavana bajaj [:bajaj]]

Marking status-firefox27 as fixed given this is resolved by https://bugzilla.mozilla.org/show_bug.cgi?id=928619