Closed Bug 274557 Opened 20 years ago Closed 20 years ago

"Find again" on NEW tab searches in prev TAB and breaks

Categories

(Toolkit :: Find Toolbar, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: g.teunis, Assigned: bugzilla)

References

()

Details

When starting a search in tab1 opening a new tab2 (focussed) the find again (f3) will return results from the unfocussed tab1. After starting a new tab and closing tab1 and tab2 no other search will work anymore on the new tab. I've created an testcase on the above URL.
According to comments on bug 255193, this should be fixed. *** This bug has been marked as a duplicate of 255193 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
(In reply to comment #1) > According to comments on bug 255193, this should be fixed. > > *** This bug has been marked as a duplicate of 255193 *** After looking into this some more this duped bug is NOT the same. In my bug the find focus error is only triggered when opening a new tab between the find and find again. I'm not able to reproduce the bug #255192. Please de-dupe my bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Breaks: when you close the "find" tab and the "find-again new tab" then FF will not search anymore. Sometimes I am able to CRASH the browser by using FAYT on this. (will post the talkbalk ID when I get one) Please note: this ONLY occures when a NEW tab is opened after Find and the find again is used on the NEW tab. (only switching to other tab works fine).
Summary: Find again on Find and FAYT not focussed to new tab and breaks → "Find again" on NEW tab searched in prev TAB, and breaks
(In reply to comment #3) > Sometimes I am able to CRASH the browser by using FAYT on this. > (will post the talkbalk ID when I get one) Here's one: TB2548045E I am encountering this crash frequently, as I use FAYT a lot (accessibility.typeaheadfind.linksonly=true). I hadn't filed anything on it previously, since I have repacked some extensions to work with the trunk and thought it might have been related to that. I am also using WinXP. For me, I hit Ctrl-T to open a new tab and then start to type, but instead of the text being entered into the URLbar, the focus is not on the URLbar and it triggers FAYT. This frequently causes a crash.
Summary: "Find again" on NEW tab searched in prev TAB, and breaks → "Find again" on NEW tab searches in prev TAB, and breaks
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041216 Firefox/1.0+ I was not able to crash, but did see the behavior noted in the testcase (only when I enable the "select new tabs opened by links" option). I normally keep the focus on the page I'm at when opening new tabs through links, so I didn't see this bug until I made the change in the options. Also, I noticed that if I pressed enter or F3 after typing in the search string to select the next match in tab1, there was nothing wrong with the functionality when I opened tab2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
My TalkbackID: 2545915 But I think these crashes are bug 274625.
Regressed between 2004-12-08-07 and 2004-12-09-07 builds on Linux, which is where I've seen the bug. Changing OS to all, hoping someone who understands the code can take it further from here...
OS: Windows XP → All
Fixes for that period: bug 237977 [Core]-Infinite javascript loop could not stopped. [All] bug 238530 [Core:SVG]-Implement SVG markers [All] bug 243869 [Core]-js_ReportUncaughtException doesn't propagate filename/lineno from error object [All] bug 239635 [Core]-add support for ignoring assertions on windows (windbgdlg) [Win] bug 271702 [Firefox]-Change in boxobject breaks autoscroll in Firefox [All] bug 272151 [/url][Core]-reorganize files within layout [All] bug 272471 [Core]-[FIX]Revamp the docshell/docloader relationship [Lin] bug 272678 [Firefox]-allowed sites/exceptions list for popup-blocking/software install/imges/cookies empty [All] bug 273158 [Core]-[FIXr]Page do not re-render if page.html#name -> page.html [All] bug 273518 [Firefox:Help]-Home button displays wrong content pack, and defaultTopic is hardcoded [All] bug 273678 [Toolkit]-nsChromeRegistry::ProcessNewChromeBuffer never flushes the profile chrome.rdf [All] bug 273741 [Core]-Copy from textarea truncated at first instance of < [All] partial fixes: bug 221619 [Core]-[Meta] Tree widget refactoring and enhancement [All] bug 1273056 [Core]-PluginArrayImpl::GetLength should not throw if there's no plugin host, and PluginArrayImpl::GetPlugins should handle no plugin host and failure from mPluginHost->GetPlugins [Win] Other regression (UNCO) that was reported to occur for the same day: bug 274553 [Firefox] Blocking iframes either via an extension or userchrome.css breaks find toolbar search. [Win]
should the issue of the find toolbar being triggered when trying to enter URL in new tab be spun off into another bug? (which I've been encountering quite often.) or would it be the same as the one originally reported here?
Summary: "Find again" on NEW tab searches in prev TAB, and breaks → "Find again" on NEW tab searches in prev TAB and breaks
(In reply to comment #9) > should the issue of the find toolbar being triggered when trying to enter URL in > new tab be spun off into another bug? I think that is bug 230401 which is not a find toolbar bug but a keyboard focus bug.
(In reply to comment #10) > > should the issue of the find toolbar being triggered when trying to enter URL in > > new tab be spun off into another bug? > > I think that is bug 230401 which is not a find toolbar bug but a keyboard focus bug. > in bug 230401, the new tab is created via double-clicking --I almost always open new (blank) tabs by hitting ctrl+T...
(In reply to comment #11) > in bug 230401, the new tab is created via double-clicking --I almost always open > new (blank) tabs by hitting ctrl+T... Okay. I am not able to reproduce your find toolbar popup bug (triggered by entering an URL after new tab). So I think it is not related to this bug.
okay, I've spun off bug 277024 for what I experience.
Flags: blocking-aviary1.1?
Find is really broken when using tabs. Find (not again) on a second tab also searched in first tab most of the time, summary isn't totally right I guess.
Is this still broken? I am not seeing it at all.
(In reply to comment #15) > Is this still broken? I am not seeing it at all. I confirm. It seems to be fixed indeed.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050228 Firefox/1.0+ ->RESOLVED/WFM
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
Flags: blocking-aviary1.1?
After some close inspection: This is not fixed yet for FAYT. Please follow instructions by starting search using FAYT on the first tab. On the second tab open the searchbar with CTRL-F and press F3 6 times. It will result in a "No More results" (previous 5 are found on prev tab but not displayed in statusbar). This will result in not being able to search in the second tab when using FAYT (try searching "New Tab" text from second tab).
it works if I use /find me or 'find me
(In reply to comment #19) > it works if I use /find me or 'find me It doesn't here: please make sure to use a clear browser. browse to above link and start FAYT search "find me". Do not press f3 or so. Open the second tab (using the step 2 link) Open CTRL-F (the searchbar) on the second tab and press F3 a couple of times, the sixth time you will notice it will display "No more results" clearly it was searching on the first tab. Are you also able to start searching on the second tab (ie. the text New tab)?
I've updated the testcase for the FAYT error. (on the above URL) Could you please check it? (can't believe my browser is the only one able to see this).
Reopening. It's definitely not fixed on the latest WinXP build. For me, it's as simple to reproduce as: - Open browser with fresh, new blank window (although I suspect any home page would do as well). - Hit ctrl-f to open find-as-you-type bar at the bottom. - Observe that the focus (cursor) is in the FAYT bar. Leave it there. Don't touch anything. - Hit ctrl-t to open a new tab. - In the new tab, try entering a url in the navigation bar, or selecting a bookmark. Notice that navigation doesn't respond.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #22) > Reopening. It's definitely not fixed on the latest WinXP build. > > For me, it's as simple to reproduce as: > - Open browser with fresh, new blank window (although I suspect any home page > would do as well). > - Hit ctrl-f to open find-as-you-type bar at the bottom. > - Observe that the focus (cursor) is in the FAYT bar. Leave it there. Don't > touch anything. > - Hit ctrl-t to open a new tab. > - In the new tab, try entering a url in the navigation bar, or selecting a > bookmark. Notice that navigation doesn't respond. Nice one! Then I open a link in the second tab (by entering a URL in the location bar) the FIRST tab is browsing to that URL the second keeps empty.
FYI: Javaconsole error while testing above testcase. (on close findbar and on creation on new tab) Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: chrome://global/content/findBar.js :: getSelectionControllerForFindToolbar :: line 210" data: no]
Flags: blocking-aviary1.1?
Due to the fix of bug 278544 this one is totally fixed for me. My testcase is working as it should. Wayne Woods' error/testcase works as expected here now. Can you confirm Wayne Woods and mark this RESOLVED if it is fixed for you?
Yep, it works for me! Resolving. Thanks.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
Flags: blocking-aviary1.1?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.