Find Bar: Number of found hits does not change when change TAB
Categories
(SeaMonkey :: Find In Page, defect)
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.
Reporter | ||
Comment 1•8 years ago
|
||
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
Reporter | ||
Comment 2•8 years ago
|
||
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)
Reporter | ||
Comment 3•8 years ago
|
||
Version due to Comment 1
Reporter | ||
Comment 4•8 years ago
|
||
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 :-). )
Comment 6•8 years ago
|
||
Suggested fix: Our findbar.xml should listen for the "TabSelect" event and then update the count.
Comment 8•7 years ago
|
||
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?
Reporter | ||
Comment 9•7 years ago
|
||
(In reply to Daksh Anand from comment #8) Please read <https://wiki.mozilla.org/SeaMonkey/FAQ#How_To_Start_Contributing_Code>, follow adivice.
Comment 10•7 years ago
|
||
(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?
Comment 11•7 years ago
|
||
(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?
Comment 12•5 years ago
|
||
Hi, I am new to the community and would like to fix this bug. Please help me fix it.
Reporter | ||
Comment 13•5 years ago
|
||
(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.
Comment 14•5 years ago
|
||
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?
Reporter | ||
Comment 15•5 years ago
|
||
I don't think that Philipp will do mentoring.
@khyati.agarwalss
Thank you for testing, I will send osme morte hints by email.
Reporter | ||
Comment 17•5 years ago
|
||
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"
Comment 18•5 years ago
|
||
This issue is solved with Firefox, but not with Seamonkey.
Comment 19•5 years ago
|
||
(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.
Reporter | ||
Comment 20•5 years ago
|
||
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?
Updated•4 years ago
|
Updated•4 years ago
|
Comment 21•3 years ago
|
||
Has this issue been resolved, if not yet then can I work on this issue?
Comment 22•3 years ago
•
|
||
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?
Updated•3 years ago
|
Reporter | ||
Comment 23•2 years ago
|
||
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
Description
•