321014 - Find in this page... should keep state

Status: NEW

(Toolkit :: Find Toolbar, defect, P5)

Description

[Lloyd Wood]

Find in this page... keeps state inconsistently.

If you have tabs open, anything typed into the Find box is persistent, and will stay there, as the Find box does.

If you do not have tabs open, the Find box vanishes as soon as you click on the window. When you bring it up again (via / or Find...) it has lost its content.

Behaviour with a single pane should follow behaviour with multiple panes, and what is typed should persist, even if the Find window doesn't.

(Also, why is the Find box at the bottom of the screen? It could be integrated into the search engine search, with its options popping up below when in use.)

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Clicking the content area only closes the findbar if it was opened by find-as-you-type or one of the shortcut keys ("'", "/"), with or without tabs.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Marking INVALID, please reopen if you disagree.

Comment 3

[Lloyd Wood]

Reopening. The find box does still not keep state of previous search terms consistently; it should.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Can you give some steps to reproduce the issue? I still don't understand what the problem is (bug 313653, maybe?).

Comment 5

[Lloyd Wood]

Press / to bring up Find box. Type 'hello' in Find box. Dismiss Find box, either by closing it or clicking in window.

Press / to bring up Find box again. Find box is empty. Find box should contain 'hello'. The search term (in this case, the string 'hello') does not persist and has to be typed again, when in fact t should persist and should appear highlighted for easy one-key deletion.

This is a separate issue from bug 313653, which relates to results, not input. I hope that's more than sufficiently clear to you.

(Do you mark all bug reports you admit you don't understand as INVALID and RESOLVED?)

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> Press / to bring up Find box. Type 'hello' in Find box. Dismiss Find box,
> either by closing it or clicking in window.
> 
> Press / to bring up Find box again. Find box is empty. Find box should contain
> 'hello'. The search term (in this case, the string 'hello') does not persist
> and has to be typed again, when in fact t should persist and should appear
> highlighted for easy one-key deletion.

"/" to open the find bar is "type as you find", the fact that it doesn't persist state in this case is intentional (see http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/typeaheadfind/content/findBar.js&rev=1.33&mark=633#620 ). There's no sense in persisting the value, that would prevent you from searching from something else, which is the entire point of find-as-you-type. Using Ctrl+F to explicitly open the find bar persists the value as you expect. I still think this is INVALID.

> (Do you mark all bug reports you admit you don't understand as INVALID and
> RESOLVED?)

No, the original issue you described was invalid, per my comment #1. You replied that there was another issue and reopened, I asked for clarification.

Comment 7

[Lloyd Wood]

> There's no sense in persisting the value, that would prevent you from
> searching from something else, which is the entire point of find-as-you-type.

Persist the value and bring it up highlighted so that one touch of backspace deletes it - or a cursor movement permits modification. This is find-as-you-type -- spend some time playing with searching in emacs.

The Find box looks the same whether it is invoked by / or by ctrl-F. I fail to see why it should be treated differently. The line deliberately removing previous content should be removed from the code.

(Another issue? My opening comments clearly mentioned state, content and persistence.)