Open Bug 1242241 Opened 8 years ago Updated 2 years ago

Find Bar: Number of found hits does not change when change TAB

Categories

(SeaMonkey :: Find In Page, defect)

SeaMonkey 2.5 Branch
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: RainerBielefeldNG, Unassigned)

References

Details

(Keywords: good-first-bug, Whiteboard: [gfb][lang=js/xbl][easyconfirm])

Steps how to reproduce with  SeaMonkey German 2.39 final Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area)  Gecko/20100101  Firefox/42.0  Build 20151103191810  (Classic Theme) on German WIN7 64bit:
1. Open <https://en.wikipedia.org/wiki/Thomas_Robertson_%28Ontario_politician%29>
2. Open new TAB
3. In new TAB open <https://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project>
4. In "Mozilla_Corporation ..." TAB: '<ctrl+f> for fid bar → "Iceweasel"
    → ˅' finds 24 hits, and bar tells something like "5 for 24 hits"
5. In "Thomas_Robertson ..." TAB:  '<ctrl+f> for fid bar → "Iceweasel"
    → ˅' finds 0 hits, and find bar tells something like 
    "Nothing found"
6. Switch back to "Mozilla_Corporation ..."
   Expected: Find Bar should show old result "5 for 24 hits"
   Bug: find bar tells "Nothing found" result from 
   "Thomas_Robertson ..."
 
Additional information
a) FF 46.0a1 (2016-01-10) correctly switches find bar results with
   TAB switches
b) A modified test shows an other difference between FF and SM behavior:
   Do test again starting with step 1, but in step 5 find "Robertson"
   (Will find 6 hits)
   continue, and in step 6 now in find bar you will see 
   '"Robertson" 2 of 6 hits'
b1) different ot FF now find bar shows the search string of the 
   previous TAB view. I can't tell whether this is a bug or a feature
b11) Feature: If you want to check different Web pages with in different
     TABS for the same string, SM behavior "keep search string"
     is favorable
b12) In most cases (I think) the replaced search string when return to
     TAB is annoying
     And the wrong find result definitively is a problem.
c) SM 2.0 did not have a find bar as we know it now
d) Already REPRODUCIBLE with  DE  SeaMonkey 2.5  (Windows NT 6.1; WOW64; rv:8.0.1)  
   Gecko/20111121  Firefox/8.0.1   Build 20111121045514  (Classic Theme) 
   on German WIN7 64bit. Design of find bar was a little different to nowadays,
   but step 6 bug and (b) behavior are already the same
e) EPRODUCIBLE with  English SeaMonkey 2.43a1  (X11; Linux x86_64; rv:46.0)
   Gecko/20100101 Firefox/46.0 Build 20160109003001  (Default Classic Theme) on 
   VirtualBox Ubuntu 14.04 LTS
f) Not Theme related, all the same with "Modern" Theme.
g) find in E-Mail not affected, still uses old floating find dialog 
h) find in E-Mail composition not affected
i) Composer not affected (no TABs, page related find bar)
OS: Windows 7 → All
Hardware: Unspecified → All
Whiteboard: [easyconfirm]
Version due to Comment 1
Version: SeaMonkey 2.39 Branch → SeaMonkey 2.5 Branch
k) only for the sake of completeness: Problem also is visible for newly opened
   TABs
Confirmed.

(Heh.  I'm glad enough that at least the search term will persist a new tab :-). )
Suggested fix: Our findbar.xml should listen for the "TabSelect"  event and then update the count.
Mentor: philip.chee, neil
Whiteboard: [easyconfirm] → [good first bug][gfb][lang=js/xbl][easyconfirm]
New due to Comment 5
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am new to open source and would like to take this as my first bug. Can the mentors please help me where to get started and assign the bug to me?
(In reply to Daksh Anand from comment #8)
Please read <https://wiki.mozilla.org/SeaMonkey/FAQ#How_To_Start_Contributing_Code>, follow adivice.
(In reply to Rainer Bielefeld from comment #9)
I meant where do i have to make changes in the code base to correct this error?
(In reply to Rainer Bielefeld from comment #0)
> Steps how to reproduce with  SeaMonkey German 2.39 final Mozilla/5.0
> (Windows NT 6.1; WOW64; rv:42.0 from official download area)  Gecko/20100101
> Firefox/42.0  Build 20151103191810  (Classic Theme) on German WIN7 64bit:
> 1. Open
> <https://en.wikipedia.org/wiki/Thomas_Robertson_%28Ontario_politician%29>
> 2. Open new TAB
> 3. In new TAB open
> <https://en.wikipedia.org/wiki/
> Mozilla_Corporation_software_rebranded_by_the_Debian_project>
> 4. In "Mozilla_Corporation ..." TAB: '<ctrl+f> for fid bar → "Iceweasel"
>     → ˅' finds 24 hits, and bar tells something like "5 for 24 hits"
> 5. In "Thomas_Robertson ..." TAB:  '<ctrl+f> for fid bar → "Iceweasel"
>     → ˅' finds 0 hits, and find bar tells something like 
>     "Nothing found"
> 6. Switch back to "Mozilla_Corporation ..."
>    Expected: Find Bar should show old result "5 for 24 hits"
>    Bug: find bar tells "Nothing found" result from 
>    "Thomas_Robertson ..."
>  
> Additional information
> a) FF 46.0a1 (2016-01-10) correctly switches find bar results with
>    TAB switches
> b) A modified test shows an other difference between FF and SM behavior:
>    Do test again starting with step 1, but in step 5 find "Robertson"
>    (Will find 6 hits)
>    continue, and in step 6 now in find bar you will see 
>    '"Robertson" 2 of 6 hits'
> b1) different ot FF now find bar shows the search string of the 
>    previous TAB view. I can't tell whether this is a bug or a feature
> b11) Feature: If you want to check different Web pages with in different
>      TABS for the same string, SM behavior "keep search string"
>      is favorable
> b12) In most cases (I think) the replaced search string when return to
>      TAB is annoying
>      And the wrong find result definitively is a problem.

Mozilla Firefox 47.0 seems to run fine. After change of tabs I can see that the search count is correctly shown in both the tabs. Is this bug solved already?

Hi, I am new to the community and would like to fix this bug. Please help me fix it.

(In reply to khyati.agarwalss from comment #12)

Hi, I am new to the community

For helping you we will need some information concerning your skills, I sent a note to you at hackerearth.

I tested for this bug, and yes it's there. I'm not able to attach the images with this comment. Should I email them?

I don't think that Philipp will do mentoring.

@khyati.agarwalss
Thank you for testing, I will send osme morte hints by email.

Mentor: philip.chee → RainerBielefeldNG

I wonder whether this one is related to or even DUP of "Bug 892384 - When switching to a tab with an open find bar, focus it"

See Also: → 892384

This issue is solved with Firefox, but not with Seamonkey.

(In reply to khyati.agarwalss from comment #18)

This issue is solved with Firefox, but not with Seamonkey.
I checked with Firefox, and it's working fine.

khyati will now setup the environment and try to do the analog fix for SM.

@frg:
Can you please help a little with installing build environment and so on if necessary? Or encourage someone else?

Assignee: nobody → khyati.agarwalss
Mentor: RainerBielefeldNG, neil → frgrahl
Status: NEW → ASSIGNED
Keywords: good-first-bug
Whiteboard: [good first bug][gfb][lang=js/xbl][easyconfirm] → [gfb][lang=js/xbl][easyconfirm]
Assignee: khyati.agarwalss → nobody
Status: ASSIGNED → NEW

Has this issue been resolved, if not yet then can I work on this issue?

sanjana2000d I still see the issue in 2.53.6b1

This is a bug against SeaMonkey not Firefox. Do you have a build environment set up?

Mentor: frgrahl

Still REPRODUCIBLE with installation of unofficial (by wg9s) De SeaMonkey 2.53.13 beta 1 pre Mozilla/5.0 (NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0 Build 20220608203253 (Newly created User Profile Default Classic Theme) on German WIN10 64bit

You need to log in before you can comment on or make changes to this bug.