551185 - autocomplete search results are empty when list is scrolled

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Aakash Desai [:aakashd]]

Build Id:
Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2.2pre) Gecko/20100309 Namoroka/3.6.2pre Fennec/1.1a2pre

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a2pre) Gecko/20100309 Namoroka/3.7a2pre Fennec/1.1a2pre

Steps to Reproduce:
1. Open the awesome bar
2. search for "moz"
3. clear the search string
4. scroll the awesome bar until the see all bookmarks row entry is not visible
5. type in "moz" again

Actual Results: 
The number of results go from 2 to 3

Expected Results
The number of results should not lower if the list is scrolled.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Vivien, can you take a look at this?

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

This is a regression we have done for performance reason a few month ago, while investigating why the awesome panel was so slow to show and discover that checking and setting the position into invalidate was slow (bug 513949)

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 431827 [details] [diff] [review]
Patch

>diff -r d5b24ba0dd28 chrome/content/browser.xul
>                              flex="1"
>+                             oninput="this.popup.scrollToTop()"

Is there somewhere in the XBL we can put this call?

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch v0.2

(In reply to comment #3)
> (From update of attachment 431827 [details] [diff] [review])
> >diff -r d5b24ba0dd28 chrome/content/browser.xul
> >                              flex="1"
> >+                             oninput="this.popup.scrollToTop()"
> 
> Is there somewhere in the XBL we can put this call?

yep. This is address as an <handler/> in this patch

Comment 5

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

Comment on attachment 432567 [details] [diff] [review]
Patch v0.2

Hmm, so this undoes the optimization from bug 513949 for the typing case, but I guess we need to do that for correctness.

I guess we don't want to just back out bug 513949 because it still helps first-open of the awesomebar? (i.e. invalidate() is called in that case, but the input handler isn't)

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #5)
> (From update of attachment 432567 [details] [diff] [review])
> Hmm, so this undoes the optimization from bug 513949 for the typing case, but I
> guess we need to do that for correctness.

So it seems

> I guess we don't want to just back out bug 513949 because it still helps
> first-open of the awesomebar? (i.e. invalidate() is called in that case, but
> the input handler isn't)

Yeah, initial open can still benefit from bug 513949

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed:
http://hg.mozilla.org/mobile-browser/rev/522328ec47cd

Comment 8

[Aakash Desai [:aakashd]]

litmus testcase https://litmus.mozilla.org/show_test.cgi?id=11621 has been created to regression test this bug.

Comment 9

[Aakash Desai [:aakashd]]

verified FIXED On builds:

Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2.2pre) Gecko/20100317 Namoroka/3.6.2pre Fennec/1.1a2pre

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a3pre) Gecko/20100317 Namoroka/3.7a3pre Fennec/1.1a2pre