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
•