629661 - Find in Page does not reset after it is closed

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P3)

Description

[Anna (Waverley)]

BUILD ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b11pre) Gecko/20110128 Firefox/4.0b11pre Fennec /4.0b5pre 

Device: Motorola Droid 2 (Android 2.2)

Steps to reproduce:    
1. Go to about:home
2. Go to the site menu -> Find In Page
3. Type the string "test" -> observe the field background color goes red
4. Dismiss the find helper by tapping in the content
5. Go to the site menu -> Find In Page

Actual result:
First of all, when typing the string "test", the field background color does not go red. After step 5, the find textfield still has a red color. Please see video: http://www.youtube.com/user/qaioana#p/u/0/t4M43c7Xc_M

Expected result:
After step 5, The find textfield has a normal background color (white).

Note 1: 
1. If you type the string "test",
2. Press the search button from VKB,(this is an important step)
    => only then the find textfield goes red.
Now, if you dismiss the find helper by tapping in the content and go to the site menu -> Find in Page => the textfield will have a normal background color. Please see video: http://www.youtube.com/user/qaioana#p/u/0/Ol83Jx22WZs

Note 2:
1. If you type the string "test"
2. Press the search button from VKB => the find textfield goes red.
3. Tap the “X” button 

Actual results:
 Tapping the "X" button will empty input field, but the textfield color is still red.  see video: http://www.youtube.com/user/qaioana#p/u/0/e7OTMDkCjeU

Expected results:
The textfield color should go whit, since the search term with no matching was removed.

Comment 1

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

Attachment: Patch - listen for text event

I think the patch cover the bug Madhava's was describing during the meeting yesterday.

Comment 2

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

Comment on attachment 509396 [details] [diff] [review]
Patch - listen for text event

we are changing the way TabClose works here. The "browser" is now dead by the time TabClose is fired. The chromeTab is now removed from the document too. I'd worry that the event wouldn't even fire correctly, since the element is no longer in the DOM.

Comment 3

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

Hmm this looks like the patch from bug 629665

Comment 4

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

Attachment: Patch

Oups wrong patch!

Comment 5

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

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

interesting use of "text" events. we might be able to use this in other search boxes

Comment 6

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

http://hg.mozilla.org/mobile-browser/rev/e8490e7e7819

Comment 7

[Anna (Waverley)]

VERIFIED FIXED on
Mozilla /5.0 (Android;Linux armv7l;rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre Fennec /4.0b5pre 

Device: Motorola Droid 2 (Android 2.2)

Comment 8

[Anna (Waverley)]

Oops! Wrong bug! Last comment was set by mistake!

Please see the above comments:


Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b12pre) Gecko/20110208
Firefox/4.0b12pre Fennec /4.0b5pre 

Device: Motorola Droid 2 (Android 2.2)

The issue from Steps to reproduce is verified fixed, but I can still reproduce
the comment from Note 2:

1. If you type the string "test"
2. Press the search button from VKB => the find textfield goes red.
3. Tap the “X” button 

Actual results:
 Tapping the "X" button will empty input field, but the textfield color is
still red.  see video: http://www.youtube.com/user/qaioana#p/u/0/e7OTMDkCjeU

Expected results:
The textfield color should go white, since the search term with no matching was
removed.

I did not filed a different bug because I thought they were related. (Should I
file a new one? )

Also after fixing the bug I noticed something else:

Steps to reproduce:  
1. Go to about:
2. Go to the site menu -> Find In Page
3. Type the string "test" -> observe the field background color goes red
4. Tap the “X” button -> this will empty the input field.
5. Type in the string "mozilla".

Actual results:
The erased string remains in the autosuggestion bar. The user can not type in
any string, unless he deletes the text from the autosuggestion bar. Please see
the following video: http://www.youtube.com/watch?v=wZEoSgUvJag

Expected results:
The user should be able to continue typing in the input text field after
tapping the X button.

Is the last issue related with this bug? Or should I file a new bug?

Comment 9

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

(In reply to comment #8)
> Oops! Wrong bug! Last comment was set by mistake!
> 
> Please see the above comments:
> 
> 
> Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b12pre) Gecko/20110208
> Firefox/4.0b12pre Fennec /4.0b5pre 
> 
> Device: Motorola Droid 2 (Android 2.2)
> 
> The issue from Steps to reproduce is verified fixed, but I can still reproduce
> the comment from Note 2:
> 
> 1. If you type the string "test"
> 2. Press the search button from VKB => the find textfield goes red.
> 3. Tap the “X” button 
> 
> Actual results:
>  Tapping the "X" button will empty input field, but the textfield color is
> still red.  see video: http://www.youtube.com/user/qaioana#p/u/0/e7OTMDkCjeU
> 
> Expected results:
> The textfield color should go white, since the search term with no matching was
> removed.
> 
> I did not filed a different bug because I thought they were related. (Should I
> file a new one? )

Well for some reasons I have always thought this is expected but not sure why.

> Also after fixing the bug I noticed something else:
> 
> Steps to reproduce:  
> 1. Go to about:
> 2. Go to the site menu -> Find In Page
> 3. Type the string "test" -> observe the field background color goes red
> 4. Tap the “X” button -> this will empty the input field.
> 5. Type in the string "mozilla".
> 
> Actual results:
> The erased string remains in the autosuggestion bar. The user can not type in
> any string, unless he deletes the text from the autosuggestion bar. Please see
> the following video: http://www.youtube.com/watch?v=wZEoSgUvJag
> 
> Expected results:
> The user should be able to continue typing in the input text field after
> tapping the X button.
> 
> Is the last issue related with this bug? Or should I file a new bug?

This issue is a regression from my fix to this bug :/

Comment 10

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

Attachment: Patch - followup

followup that fix Anna's comments.

Comment 11

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

I've generalized the code so it will also work for the addon's search textbox.

Comment 12

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

Comment on attachment 510692 [details] [diff] [review]
Patch - followup

>diff --git a/chrome/content/bindings.xml b/chrome/content/bindings.xml

>+      <handler event="click" phase="bubbling">
>+        <![CDATA[
>+          if (event.originalTarget == this._searchClear) {
>+            setTimeout(function(self) {
>+              self.inputField.readOnly = true; 
>+              self.inputField.readOnly = false;
>+            }, 0, this);

A comment as to why you need to do this would be nice. Can we fix something in the platform to make this not needed?

r+ with comment

Comment 13

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

http://hg.mozilla.org/mobile-browser/rev/9edc4db92535

Comment 14

[Anna (Waverley)]

VERIFIED FIXED on:
Build Id:
Mozilla /5.0 (Android;Linux armv7l;rv:2.0b12pre) Gecko/20110210
Firefox/4.0b12pre Fennec /4.0b5pre 

Device: Motorola Droid 2 (Android 2.2)