404773 - Find bar doesn't like the letters 'b', 'o', 'd', 'y', and 'random'

Status: VERIFIED FIXED

(Toolkit :: Find Toolbar, defect, P1)

Description

[Johnathan Nightingale [:johnath]]

On current trunk, I am getting extremely weird findbar behaviour.

To reproduce:

1) Go to http://www.mozilla.com/en-US/
2) Open the quickfind bar
3) To confirm your sanity, search for "message" and see it highlighted
4) Now backspace up to just the 'm' and watch the highlight respond accordingly
5) Now append "oessage" so that you're searching for "moessage" - be sad, because "message" is still highlighted.  'o' is being ignored in this case.
6) Now clear all that out, and search for something that's supposed to have an 'o', like, say, "Mozilla".  Be sad, because it doesn't seem to be found.

Might be mac-specific?  Seems to be pretty recent.  Nothing in the error console.

I don't know if other letters have also regressed.

Comment 1

[[e-mail] (:bhearsum)]

Can't repro on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112106 Minefield/3.0b2pre. 'o' and 'O' work just like any other letters.

Comment 2

[Brian Polidoro]

Sounds similar to bug 404094.  

Comment 3

[Dave Camp (:dcamp)]

I am seeing this too, on mac.

Comment 4

[Dave Camp (:dcamp)]

b, d, and y seem to be unhappy too.

Comment 5

[Andreas Goetz]

Cannot reproduce on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112805 Minefield/3.0b2pre

Comment 6

[Johnathan Nightingale [:johnath]]

This does seem to be mac-specific, but tracking down a regression range is difficult - I can't seem to reproduce this on nightlies right through to yesterday, but see it consistently on my trunk builds, on both old and new profiles.  On the other hand, gavin can't reproduce this on his trunk builds with old or new profiles.

Comment 7

[Dave Townsend [:mossop]]

I've seen this twice in the past day. Seems there are a bunch of letters that if you just search for them on their own no results are found and if they appear in a search with other letters they are just ignored.

I don't know if it was related (probably just a coincidence) but I first saw it on a custom build I did with bug 392785 backed out locally and then I second saw it when using today's build, the first which had that bug backed out too.

Comment 8

[Martijn Wargers (dead)]

Related to bug 379280? (although I can't seem to reproduce this one with the steps to reproduce)

Comment 9

[Dave Townsend [:mossop]]

Attachment: patch rev 1

Turns out unterminated strings are a bad thing.

The call to StripChars was getting the soft hyphen, plus whatever characters following the array in memory till the next null. Something changed recently that caused certain builds to include about 3 random characters followed by a "body" literal to fall there.

There's a reasonable chance that this could have been causing other characters to fail at random times.

Comment 10

[Dave Townsend [:mossop]]

Randomly occuring regression from bug 294615

Comment 11

[Mike Schroepfer]

Moving to p1 - we should really get this for b2...

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 291924 [details] [diff] [review]
patch rev 1

Nice :)

r+sr=jst

Comment 13

[Johnny Stenback (:jst)]

Should we try to push this in for beta2? Totally safe, trivial, and obvious patch.

Comment 14

[Dave Townsend [:mossop]]

P1 blocking means it can land so land it has!

Checking in embedding/components/find/src/nsFind.cpp;
/cvsroot/mozilla/embedding/components/find/src/nsFind.cpp,v  <--  nsFind.cpp
new revision: 1.48; previous revision: 1.47
done

Comment 15

[Asaf Romano (gone)]

Thanks Dave!

Comment 16

[Marcia Knous [:marcia]]

verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007120705 Minefield/3.0b2pre. I verified using the STR in Comment 0.