Closed Bug 629661 Opened 9 years ago Closed 9 years ago

Find in Page does not reset after it is closed

Categories

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

ARM
Android
defect

Tracking

(fennec2.0+)

VERIFIED FIXED
Tracking Status
fennec 2.0+ ---

People

(Reporter: anamaria.moldovan, Assigned: vingtetun)

Details

Attachments

(3 files)

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.
tracking-fennec: --- → ?
Priority: -- → P3
Assignee: nobody → 21
tracking-fennec: ? → 2.0+
I think the patch cover the bug Madhava's was describing during the meeting yesterday.
Attachment #509396 - Flags: review?(mark.finkle)
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.
Hmm this looks like the patch from bug 629665
Attached patch PatchSplinter Review
Oups wrong patch!
Attachment #509432 - Flags: review?(mark.finkle)
Comment on attachment 509432 [details] [diff] [review]
Patch

interesting use of "text" events. we might be able to use this in other search boxes
Attachment #509432 - Flags: review?(mark.finkle) → review+
http://hg.mozilla.org/mobile-browser/rev/e8490e7e7819
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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)
Status: RESOLVED → VERIFIED
Status: VERIFIED → RESOLVED
Closed: 9 years ago9 years ago
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?
(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 :/
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch Patch - followupSplinter Review
followup that fix Anna's comments.
Attachment #510692 - Flags: review?(mark.finkle)
I've generalized the code so it will also work for the addon's search textbox.
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
Attachment #510692 - Flags: review?(mark.finkle) → review+
http://hg.mozilla.org/mobile-browser/rev/9edc4db92535
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
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)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.