Open Bug 920031 Opened 11 years ago Updated 2 years ago

Find text is not remembered between tabs (e.g. when Find Again)

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Points:
5

Tracking

()

People

(Reporter: ldubox-coding101, Unassigned)

References

Details

(Whiteboard: [testday-20130927])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20130917123208 Steps to reproduce: I suspect this change was intentional. However, may I offer a workflow scenario which this breaks, and which I can't see myself adapting to: 1. Open a series of pages on new tabs (e.g. middle click) to search the contents 2. Search for a word of interest (simply type it). Press F3 a few times to scan the page. 3. Move onto the next page, press F3 a few times. Weird, no match at all. Close the tab. 4. Repeat step 3 numerous times ... 5. Eventually... "hey... it's not really searching". Grrr. Start again at step 1. Actual results: F3 "appears" broken. I need to retype my search text multiple times to make it work. Expected results: F3 should just work across tabs, without having to retype the search
Blocks: 537013
I've discovered similar Bug 913536 (via 537013, thanks for the link), but FWIW I think this is a bit different. I understand that: a. Find is remembered separately per tab b. The initial value (for F3 or Ctrl+F) on a new tab is inherited from the most recent 'find' from the 'parent' tab that launched the new tabs If it helps clarify further: The 'parent' tab might be for example a Google result page, and I launch up tabs for the results that look interesting. Since I have never done a 'find' within the 'parent' tab itself, it is never suggested as the initial find string for any of the opened tabs. I should add that I really like the updated find bar, and I see a lot of work went into bug 537013 with 7 votes, but I rather wonder whether the request to additionally remember the *search terms* on a per-tab basis might have been driven by power-users rather than mainstream users(?) The implementation prior to bug 537013 seems to be the simplest 'mental model' and a more task-oriented approach. I can't imagine that many people are able to remember multiple find-terms they've entered across multiple tabs, and having old individual searches coming back from the past being what they expect. I think it's more likely that a person moves onto a new _task_ (I'm looking for XYZ now), and so the "Again" in "Find Again" would be expected to mean "do what *I* last did, again". Expectations are also driven by similarity with other software a user is familiar with. In the first two applications I sampled: * Microsoft Word (2007): remembers a single search across multiple documents * Eclipse: A single most-recent search is remembered across multiple editor tabs
I don't know if this specific case was intentional or not, but considering the new "per-tab" independent find bar, this would be at least expected (searches being independent from tab to tab). However, personally I agree that, in this situation as you described, the find bar should also assume the previous (globally) used find value, in addition to bug 913536. /spam, but relevant As a side-note, for a workaround you can use my add-on FindBar Tweak (install latest 1.4beta available! at https://addons.mozilla.org/en-US/firefox/addon/findbar-tweak/versions/ ), it should do what you want by default. And with the preference "Findbar starts closed in new tabs" disabled, it emulates the previous behavior of the old global find bar even more closely. /end-spam
(In reply to Luís Miguel [:Quicksaver] from comment #2) > (...) in this situation as you described, the find bar should also assume > the previous (globally) used find value, in addition to bug 913536. I initially thought about this too. However to special-case the "_never_ performed a find on the parent tab" scenario would be inconsistent, at best. The user might have instead, long ago, done (Ctrl+F, Banana) there. Later, they spawn tabs. They do (Ctrl+F, Mango) on the first spawned tab. On subsequent tabs, F3 searches "Banana". ("Huh? Where did that come from?") IMHO this fails the http://en.wikipedia.org/wiki/Principle_of_least_astonishment test, and so should be reconsidered in favour of a task-oriented approach: remembering a single find-term globally.
That is what I meant, tab relations is irrelevant to the point. I'm sorry if I wasn't clear; by "this situation described", I was referring to hitting F3 on a tab without a find bar open and a search run should assume the last used search value globally (on any tab in the window).
I couldn't reproduce this. Command-G and F3 does find persistently across tabs, though the Find bar at the bottom of the screen doesn't persist. Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Firefox/25.0
Component: Untriaged → Tabbed Browser
Whiteboard: [testday-20130927]
(In reply to Liz Henry :lizzard from comment #5) I suspect you are opening the find bar in the first tab, if the find bar is opened through Ctrl+F, the search persists to another tab through F3 (only the first time it is performed in the new tab!). This bug is relative to type-ahead only, as in typing in the actual webpage to access the quick find bar; I have only tested in Windows 7, maybe Mac builds don't behave the same way for some reason.
Summary: Find (again) is not remembered between tabs → Find text is not remembered between tabs (e.g. when Find Again)
Liz, if it looks like the issue doesn't reproduce you may have had the find-bar still open when you left the first tab? (ie. press escape or close the find-bar between step 2 and 3 in the steps above) It looks like the last used search value only gets saved if the find bar is actually open when switching away from a tab - see the steps in bug 920972.
To clarify, this is about _what_ text is being searched for. To reproduce the steps of the original post, you probably need to first restart firefox to hit the "nothing found at all" described in step 3. Since the original posting (I wish I could edit it) I realise this is just one symptom of a more general problem - it's remembering multiple (usually old & irrelevant) find-text, on a per-tab basis. I find this surprising, inefficient (you need to repeatedly retype the text) and different from all other software that I run. In short: a serious behavioural regression introduced with the GUI changes of bug 537013. There should be a single find-string remembered application-wide.
I was looking at this bug relative only to the "Find Again" situation isolated, which is what was described initially. What you describe in comment 8 I think is the same as in bug 920972.
I can reproduce the problem. http://hg.mozilla.org/mozilla-central/rev/8f805d3ef377 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20130929030202 Steps To Reproduce 1. Start Firefox 2. Open several tabs Ex. Open https://developer.mozilla.org/en-US/docs/Code_snippets Middle click a link "Windows code" to open in newtab Middle click a link "Toolbar" to open in newtab 3. Type "/"(without quotation) to open Quick Find 4. Type "code"(without quotation) 5. Press F3, F3 --- Find is performed properly 6. Switch to next tab 7. Press F3 --- Weird beheviour, FindBar open with empty textbox --- Find in the page is not performed at all 8. Switch to next tab 9. Press F3 --- Weird beheviour, FindBar will open with empty textbox --- Find in the page is not performed at all Actual Results: In Step 7(step9): Wird beheviour, FindBar will open with empty textbox Find in the page is not performed at all Expected results: Find in the page should perform between tabs
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Alice0775 White from comment #10) Variations: A: press F3 or ctrl-F instead of / in step 3 = everything works. B: same + also press escape to close the find bar between step 5-6 = broken again.
Alice0775, thanks for your steps to reproduce, now I see the problem on Nightly and Aurora, though it does not happen on Firefox 24.
Keywords: regressionwindow-wanted
Here is what I got from mozregression, Last good nightly: 2013-07-07 First bad nightly: 2013-07-08 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f8a08d0a1b2a&tochange=17a47dcef75d
This behavior comes as a direct consequence from the patch implemented in bug 537013, which is why it was marked as blocking it I believe.
OS: Windows 7 → All
This is the break of a killer feature for me. It immediately stood out after the automatic upgrade that I did not ask for (FF is ignoring the "Check for updates, but let me choose" pref). Was this really something that we users were clamoring for? It's a deep, fundamental feature and I'm really disappointed that it's been broken for my workflow.
Yuk. I agree with Matthew: This has seriously degraded my browsing experience. It's common for me to search for the same text in multiple pages (Google search being an obvious use case, but not the only one). We really need something in about:config to restore the old behavior. To be clear about my usage, I almost never use Ctrl+F. I just do my searches with "/" and start typing (which has the added bonus of removing the find bar automatically after N seconds). Going to another tab and pressing Ctrl+G doesn't work as the search string doesn't exist in that tab. Horrible, horrible, horrible!
Whiteboard: [testday-20130927] → [testday-20130927] p=0
Hardware: x86_64 → All
Version: 25 Branch → Trunk
19 unhappy comments on Firefox Input so far: https://input.mozilla.org/en-US/?q=f3&platform=Windows+7&date_start=2013-06-01#
Actually 38 if you remove the OS filter. https://input.mozilla.org/en-US/?q=f3&date_start=2013-06-01
This has been a god awful change. I often search for model numbers across multiple pages and now it no longer works when I press F3. Now I have to ctrl+F, ctrl+V whenever I switch tabs. All because someone asked for a feature on a whim, this was made across the board. For future reference, please include an option to toggle old/new behaviour for new "features" (or feature removal in this instance). Since there aren't any major improvements in FF27, I am tempted to go back a revision because of this regression.
(In reply to koonkii from comment #22) > Since there aren't any major improvements in FF27, I am tempted to go back a > revision because of this regression. https://www.mozilla.org/security/known-vulnerabilities/firefox.html#firefox27
Newsflash: users care more about usability than security vulnerabilities they don't encounter. Especially in the case of browsers, a focus on usability would result in _more_ security — users staying on up-to-date software rather than downgrading to out-of-date software in order to get back former usability. Removing this feature was a bad move on every front.
I found an addon which fixes the stupid decision made by Firefox developers. https://addons.mozilla.org/en-US/firefox/addon/globalfindbar/
What a pity having to install yet another addon only to get back usability... As if Firefox didn't use enough memory.
This bug is about fixing the specific issues described in the first few comments, not about reverting completely to the old find bar behavior. Please everyone, these comments/complaints about the new find bar vs the old find bar are misplaced in this bug thread, and will accomplish nothing here but to disrupt its workflow. These would be better placed in the link provided in comment 20.
The bug I've opened speaks about this, but the bug has been marked as duplicate of this one. The overall idea was to keep the old searchbox behaviour (keep it opened between tabs and keep same searched word(s)). https://bugzilla.mozilla.org/show_bug.cgi?id=938545
Flags: firefox-backlog?
Flags: firefox-backlog? → firefox-backlog+
No longer blocks: fxdesktopbacklog
For me, this change is crippling to the usability of FF. Comments above capture most of my thoughts on this change so I won't reiterate what has already been described. On the comment above- "We really need something in about:config to restore the old behavior"- I would just like to add that I would like to see the old behavior become the default again, and the new behavior could be enabled in about:config, if it is still desired.
Question: Is there a Mozilla process for reverting a change due to user feedback? Or is it completely developer-driven? I ask because - and I say this as a user who used to love FF but is increasingly unhappy with it - it seems development has taken on a "we know best" arrogance that sacrifices user features for some other goal. This bug is a good example as is forcing users to upgrade (i.e., making it very difficult to stay with an older, more satisfying version) or removing long-standing shortcut behavior on the Mac (you took out control-space to invoke context menus).
(In reply to Matthew Cornell from comment #35) > Question: Is there a Mozilla process for reverting a change due to user > feedback? Or is it completely developer-driven? I ask because - and I say > this as a user who used to love FF but is increasingly unhappy with it - it > seems development has taken on a "we know best" arrogance that sacrifices > user features for some other goal. This bug is a good example as is forcing > users to upgrade (i.e., making it very difficult to stay with an older, more > satisfying version) or removing long-standing shortcut behavior on the Mac > (you took out control-space to invoke context menus). Good question! Development is _not_ developer driven, but driven by (user) feedback and contributions by volunteers! This means that by all means, your feedback is always much appreciated, read, understood and taken into consideration. I do have to point out that there are better places to voice you opinion, constructive criticism and start discussions, one of which is the firefox-dev mailing list: https://mail.mozilla.org/listinfo/firefox-dev This particular bug has been nominated for the developer backlog and waiting to be picked up in one of the upcoming Firefox Desktop iterations. Before that time, any community member should feel free to pick this up and submit a patch! I'd be happy to mentor, even though this is not a good first bug.
Whiteboard: [testday-20130927] p=0 → [testday-20130927] p=5
(In reply to Matthew Cornell from comment #35) > or removing long-standing shortcut behavior on the Mac > (you took out control-space to invoke context menus). This is off topic for this particular bug, but can you provide more detail to me privately? I'm not sure we can fix anything here, but I'd like to at least understand what you're referring to better. Thank you!
Points: --- → 5
Whiteboard: [testday-20130927] p=5 → [testday-20130927]
(In reply to Mike de Boer [:mikedeboer] from comment #36) > This particular bug has been nominated for the developer backlog and waiting > to be picked up in one of the upcoming Firefox Desktop iterations. Before > that time, any community member should feel free to pick this up and submit > a patch! I'd be happy to mentor, even though this is not a good first bug. This is very encouraging! I haven't commented on any of these find bar related bugs yet as comment 59 [1] from bug 537013 implied that Mozilla weren't interested in having this as a preference. Your suggestion of submitting a patch is the first time I've seen it suggested otherwise. Presumably such a patch can mostly be constructed from the removed lines of the patch that altered this behaviour, but with some added preference code. I'll have a play if it's within my capabilities. FWIW, it would be greatly appreciated if long-standing behaviour altering/removing changes in Firefox could be toggled with preferences rather fully altered/removed. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=537013#c59
It also common for me to search for the same text in multiple pages, and while <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=537013 ">Find Bar Tweak </a> worked for a while in keeping the bar open across tabs, a recent (32 or 33) FF update results in the search string being blanked when switching to a new tab. Like as ctrl+tab can be toggled to switch btwn most recently viewed tabs (which me thinks should be the default behavior!), so should the find bar function.
It seems what i wrote before about FBT not keeping the same search string in other tabs was due to something on my profile. I loaded another profile under FF 33.1.1 with the same FBT settings and found it Find Bar Tweak is staying visible keeping the same search string in other tabs, which I think should be an option for the default FF find bar.
The title of the bug "Find text is not remembered between tabs (e.g. when Find Again)" does not hold (any more) with Firefox v37.0.1. The fins text _is_ remembered, but it is not searched. Details: - open new window - load some page - open some links in new tab by middle-click - switch to second tab, ctrl-f for "foo" - switch to third tab, press ctrl-f: the text "foo" was remembered and is filled into the find bar automatically - switch to fourth tab... the same ... etc Note: this is about tabs with common "parent". Not sure how it affects things, just mentioning it.
PS: It appears ctrl-g also works on the other tabs, at least in the above case. (I started looking for this bug report because it did _not_ work for me in one scenario, but I forgot what was I doing differently).
David Balažic - what you were doing differently when it didn't work was probably closing the find bar before switching to the new tab. That's when it fails to remember it correctly. More details in bug 920972.
Something does seem to have improved slightly along the way, specifically where in comment 41 it says 'second tab, ctrl-f for "foo" ' Note however that I have this setting enabled: Advanced > General > Search for text when I start typing (Sorry, I could have been more explicit in my original post.) So I wouldn't press Ctrl-F in the second tab, I'd just type 'foo'. The text still appears in the find bar - so one would expect "looks the same, should act the same". However it doesn't, it is not applied to the new (never before searched) tabs. Perhaps the fix that came in was not applied generally enough to cover both search modes. Personally I find this whole endeavour to have different search-strings remembered on different tabs to be a very advanced usage, and a difficult mental model, especially as it's different to the majority of other applications out there. If power-users like it, I would think an about:config setting would be more appropriate to enable it.

I've come back from Chrome after many years, and this is tripping me up daily since I expect to be able to continue searching for the last search text in other tabs when I press F3. Chrome uses the last search text globally.

I agree very much that per-tab search text is a "difficult mental model".

It seems like even the reporter of Bug 537013 which introduced this change had thoughts about this use case, and used to rely on it themselves:

I had thought about the legitimate use case that exists now for keeping it open (there really is only one use case), but that seems like a less frequent use case than not wanting the find bar open.

For clarity: that one use case being that you want to perform the same search across multiple tabs (I know I did that when studying for exams or writing papers).

I guess an issue does come up when you want to then change the search across tabs. Chrome/Safari handle this by changing the search term across all tabs/windows. My suggestions don't cover a good way to deal with this though.
https://bugzilla.mozilla.org/show_bug.cgi?id=537013#c2

In the various bug reports, which duplicates this, there are suggestions to use addons, but the two I've found are no longer available/possible:
https://addons.mozilla.org/en-US/firefox/addon/findbar-tweak/
https://addons.mozilla.org/en-US/firefox/addon/globalfindbar/

Please reconsider reverting this, or at least make it configurable whether search text should be global across tabs.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 33 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)

(In reply to Luke Usherwood from comment #0)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101
Firefox/25.0 (Beta/Release)
Build ID: 20130917123208

Steps to reproduce:

I suspect this change was intentional. However, may I offer a workflow
scenario which this breaks, and which I can't see myself adapting to:

  1. Open a series of pages on new tabs (e.g. middle click) to search the
    contents
  2. Search for a word of interest (simply type it). Press F3 a few times to
    scan the page.
  3. Move onto the next page, press F3 a few times. Weird, no match at all.
    Close the tab.
  4. Repeat step 3 numerous times ...
  5. Eventually... "hey... it's not really searching". Grrr. Start again at
    step 1.

Actual results:

F3 "appears" broken. I need to retype my search text multiple times to make
it work.

Expected results:

F3 should just work across tabs, without having to retype the search

Yes, F3 should just work across tabs, without having to retype the search - but with the search box being visible. Note however, as regards the post above (press F3 a few times. Weird, no match at all.) that you can have a different search term being searched, depending on what the last one was and if the search box on a page was open for a previous term.

I find that after invoking F3, the search box is not visible on certain pages, although it will search the page for the last used search term. For instance, with multiple tabs open, if it hit F3 on a Ebay product page, the search box will show up in the bottom left corner, and will also show if I hit F3 on some other open tabs, as https://adentistsdaughter.com/oral-b-electric-toothbrush-comparison, but on some others the search box will not appear (unless you do ctrl+f), even if I refresh the page, such as,
it will usually https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2334524.m570.l1313&_nkw=inflating+needle&_sacat=0&LH_TitleDesc=0&_odkw=inflating+needles&_osacat=0&_sop=15

However, pressing F3 will result in searching for the last used search term (like shipping). Yet while I like the retention of search terms across tabs (unlike Vivaldi, in which I must type again every time a search a different page) this may not be the term wanted for that page. In which case ctrl+f must be pressed again to see the search box and type what you want, thus reducing efficiency.

The old Firefox the Find Bar extension fixed the issue FF had then, but what is needed is a persistent search box and the last used term, which then can be quickly changed.

Wow, thread opened 9 years ago. I was hoping for a simple setting, but I guess not.
A "find bar" unique for each tab is usually inconvenient.. a global one would be better (ideally as an option).
At least I see there's an addon again now, even if I already have too many "not actively monitored for security by Mozilla" ones..

Yes, that is the best, if second to the old Find Bar, that I have found. Note also that it offers some customization. Author seems to be an accomplished coder.

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