Closed Bug 63241 Opened 19 years ago Closed 19 years ago
'Find in this page' should search thru all frames, not just active one
spun off from bug 52727... i couldn't find an existing one for this issue. pls reassign if needed! anyhow, the summary sez it all: since mozilla/6.0 currently doesn't show which frame is active, we should thus make 'Find in this page' search through all of the frames on the page. a user shouldn't have to worry about whether or not a page has frames --Find should just search through the frames in order, without caring which one's in focus.
nav triage team: Would be nice, but.... Of course, a patch is ALWAYS welcome. ;-) Marking nsbeta1-
this should go over to Bill
Assignee: kin → law
Marking nsbeta1- bugs future
Target Milestone: --- → Future
Assignee: law → joki
Target Milestone: Future → ---
No way joki will do this. It's XPApps work.
Assignee: joki → pchen
does this belong to pchen. if yes, how can we make it for 0.9? if no, who does this belong to?
By rights, it should be assigned to me and/or Kin. To make "find" work across a frame set requires either the code driving the find/replace (in mozilla/xpfe/components/src/nsFindComponent.cpp) to cycle through the frameset, or, the underlying text services document or nsIFindReplace to do so. As to getting it in mozilla0.9...I'd look for a miracle.
I really think this should be handled by the app or front end nsFindComponent, since the backend TextServices Find code has no clue about what frame/document currently has focus, etc.
Agreed, except I'm holding out hope that if one could attach to the parent frameset, then the editor components could take care of it. How do nested <iframe>s work, currently?
You simply need to walk nsIDocShellTreeItem trees, which is fairly simple. I think the harder problem here is indicating to the user that you are doing this, and focussing the frame in which the result is found.
I would like to believe that nsIFindAndReplace::Find would do the right thing with respect to focus, etc. It already manages scrolling the found text into view and showing selection. My concern is in navigating the <frame> tree in the midst of the search. It seems kind of hard to manage this outside of nsIFindAndReplace. I think that interface, at a minimum, has to manage its nested (child) <iframe>s. It is the only object with the necessary info to possibly know when to descend into the child <iframe>s. As it stands, I can search a given document/window, but the only way to deal with child frames would be to detect the case where nsIFindAndReplace returned a failure on a search. Currently, that comes only at the end of the document. If we started searching child <frame>s at that point, then the occurrences wouldn't be found in a linear fashion. In a document with structure: <p>Some text. <iframe src="subframeContainingText.html"/> <p>Some more text. then searching from the top for "text" would match the first line, then the last line, then the contents of the child <frame>. Plus, we'd have to manage the wrap/search-backwards flags during this process (we couldn't ever pass "wrap" into nsIFindAndReplace because then we'd never know to search child <frame>s). But if nsIFindAndReplace were smart enough to recurse into its child <frame>s at the right time, then we could change nsBrowserInstance.cpp so that it searched starting at the root (GetContentWindow()) instead of GetFocusedContentWindow(). Although it would be nice to *start* the search at the focused content window... We *could* manage the cross-frame searching from outside nsIFindAndReplace if we're willing to accept the resulting non-linear "search order" and the perhaps more complicated code that results from putting control outside of that interface. In reply to Kin's comment about the lower level code not knowing about focus: I interpret this bug as saying that we basically want to ignore the focused <frame> when searching. So not knowing about focus isn't necessarily a problem. Is there any reason why we wouldn't want to deal with this in nsIFindAndReplace (and its nsITextServicesDocument)?
Do we really need to worry about the <iframe> case, or can we punt and just search each docShell in hierarchy order? Other browser actions (e.g. selection) don't treat <iframe> contents in-flow, and doing this would make the logic *much* harder.
I'm going to work on this.
Assignee: pchen → sfraser
cc valeski. We have to figure out whether this is doable without changing nsIWebBrowserFind, which is frozen.
Status: NEW → ASSIGNED
To avoid writing all the code twice, I'm going to change the Find in browser to use the same code as embedding does. This bug is therefore dependent on bug 68307.
IE 5.5 supports implicit multi frame searching. NS 4.x does not. NS 6.x does not. It's not clear to me why this would have interface ramifications. we maintain a text level cursor behind the scenes, why can't we just maintain a frame (nsIDOMWindow) cursor back in the impl too? It would start w/ the current focused frame, then wrap around the window list; no?
OK, if implicit multi-frame searching is supported on IE 5.5, that's a better precedent than the split-pane text editor model I brought up. Forget my prior reservations - I'm all for it now.
I set the target milestone to 0.9.1 (it's not needed in 0.9, but we need to have it in the following milestone).
Target Milestone: --- → mozilla0.9.1
Simon, if this could be done for soon, please reset the milestone to 0.9.
I have this pretty much working in my tree, but the changes are quite large (I had to reorganise the embedding Find code that that I can use it in the browser). I'd rather wait for 0.9.1, unless there is a real urgency to get it into 0.9.
This version of find deals with searching multiple frames, either forwards or backwards. It does not yet correctly handle wrapping while finding in multiple frames, since the underlying nsIFindAndReplace needs some API changes for this (related to bug 6915). These changes supersede the nsWebBrowserFind versions in bug 68307.
Whiteboard: Expected to land by 4/27
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
how difficult would this be to check this into 0.9 branch?
Whiteboard: Expected to land by 4/27 → needed in 0.9 branch by 05/08/01
It's do-able. I have most of the changes in a tree.
vrfy fixed: 2001.05.18.13 [comm bits] on linux, mac and winnt.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.