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)
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.
Comment 1•20 years ago
|
||
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
| Reporter | ||
Comment 2•20 years ago
|
||
(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.
| Reporter | ||
Updated•20 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
| Reporter | ||
Comment 3•20 years ago
|
||
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.
| Reporter | ||
Updated•20 years ago
|
Summary: "Find again" on NEW tab searched in prev TAB, and breaks → "Find again" on NEW tab searches in prev TAB, and breaks
Comment 5•20 years ago
|
||
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
| Reporter | ||
Comment 6•20 years ago
|
||
My TalkbackID: 2545915 But I think these crashes are bug 274625.
Comment 7•20 years ago
|
||
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
Comment 8•20 years ago
|
||
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]
Comment 9•20 years ago
|
||
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
| Reporter | ||
Comment 10•20 years ago
|
||
(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.
Comment 11•20 years ago
|
||
(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...
| Reporter | ||
Comment 12•20 years ago
|
||
(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.
Comment 13•20 years ago
|
||
okay, I've spun off bug 277024 for what I experience.
Updated•20 years ago
|
Flags: blocking-aviary1.1?
| Reporter | ||
Comment 14•20 years ago
|
||
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.
Comment 15•20 years ago
|
||
Is this still broken? I am not seeing it at all.
| Reporter | ||
Comment 16•20 years ago
|
||
(In reply to comment #15) > Is this still broken? I am not seeing it at all. I confirm. It seems to be fixed indeed.
Comment 17•20 years ago
|
||
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 ago → 20 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Flags: blocking-aviary1.1?
| Reporter | ||
Comment 18•20 years ago
|
||
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).
Comment 19•20 years ago
|
||
it works if I use /find me or 'find me
| Reporter | ||
Comment 20•20 years ago
|
||
(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)?
| Reporter | ||
Comment 21•20 years ago
|
||
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).
Comment 22•20 years ago
|
||
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 → ---
| Reporter | ||
Comment 23•20 years ago
|
||
(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.
| Reporter | ||
Comment 24•20 years ago
|
||
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?
| Reporter | ||
Comment 25•20 years ago
|
||
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?
Comment 26•20 years ago
|
||
Yep, it works for me! Resolving. Thanks.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•