One sane method of "working around" bug 85686 would be to use window.getSelection() and commonAncestorContainer to determine which form element has focus, if any. But that doesn't work because window.getSelection() says there are no selected/focused ranges when a textarea (or any form element, for that matter) has focus.

I just tried playing with your testcase on my 1.5.0.3 install, and clicking on/in any form element gives "1 selection" rather than "0 selections" like it looks like you're reporting. Am I interpreting something wrong?

I want it to say "1 selection in: TEXTAREA in BODY". What does it say for you?

It seems to leave the old selection around *if* the old selection is collapsed. So if I click in the paragraph and then click in the textarea, it still says "1 selection in: P in BODY". But if I select text in the paragraph and then click in the textarea, it says "0 selections". It never says "1 selection in: TEXTAREA in BODY" for me.

I think the relevant code is here: http://lxr.mozilla.org/seamonkey/source/layout/forms/nsTextControlFrame.cpp#1974 So the idea is to collapse the doc selection inside textcontrol's element? But that leaves still cases where the focus is on a button/link and the selection is somewhere else, so I don't see how commonAncestorContainer can be a reliable way to get the currently focused node.

That would be good enough to answer the question "what textbox or textarea, if any, has focus?". You'd have to loop through the ranges in the selection, since there could easily be 2 ranges.

This does what is desired, I think. I still don't think this will give a very good solution as to whether a text control has focus, but I think this will give at least a better behavior than what Mozilla does currently.

Actually, I don't know this code very well. :( Maybe try roc?

I'm not sure if this is a good idea. It breaks the invariant that there is at most one non-empty selection in a document. Wouldn't it make more sense to offer a method that tells you what node in the document, if any, is focused?

> I'm not sure if this is a good idea. It breaks the invariant that there is at > most one non-empty selection in a document. On Windows, you can already create multiple selections by Ctrl+clicking table cells, or by Ctrl+dragging text. *Not* fixing this breaks my assumption that focus is always represented by a (usually collapsed) selection. That assumption holds when focus is in a paragraph, but not when focus is in a textbox, which seems really strange. Btw, why preserve a text selection at all when I focus a form field? > Wouldn't it make more sense to offer a method that tells you what node in the > document, if any, is focused? That would be ideal.

(In reply to comment #9) > I'm not sure if this is a good idea. It breaks the invariant that there is at > most one non-empty selection in a document. What do you mean? With my patch, there is still only one selection in the document. Any selection in the textcontrol is not part of the document selection.

Why is this bug security sensitive?

Because you made it security-sensitive? ;)

"oops"

Argh!

Some people shouldn't be allowed near a Web browser... (In reply to comment #10) > On Windows, you can already create multiple selections by Ctrl+clicking table > cells, or by Ctrl+dragging text. That's not what I meant. In Gecko terms, that is one selection object which happens to contain multiple discontiguous ranges of content. What's actually happening here is that there are multiple different "selection objects" maintained inside Gecko. There's one for each document, and one for each textarea. I believe that currently at most one of these per top-level document should be non-empty at any given time. (So really, you can imagine that there's only one per top-level document, and I think making that true in the implementation is something that Blake wants to do eventually.) This seems to not be true based on your comment #4, but I think we probably want to make it more true rather than less true. > *Not* fixing this breaks my assumption that focus is always represented by a > (usually collapsed) selection. I think we need to avoid mixing up focus with selection here. As Martijn mentioned in comment #5, focus is usually associated with selection (usually, if there's a focused element and a selection, the focused element contains the selection) but that relationship is not really fundamental. It's the *caret* that's represented by a collapsed selection. > Btw, why preserve a text selection at all when I focus a form field? Like in comment #4? Yeah, I think we shouldn't. Focusing a text control sets the text control's caret position, i.e. sets the text control selection to some collapsed position, which should clear out any other selections under the same top-level document. > > Wouldn't it make more sense to offer a method that tells you what node in > > the document, if any, is focused? > > That would be ideal. Peter? :-)

(In reply to comment #16) > What's actually happening here is that there are multiple different "selection > objects" maintained inside Gecko. There's one for each document, and one for > each textarea. I believe that currently at most one of these per top-level > document should be non-empty at any given time. (So really, you can imagine > that there's only one per top-level document, and I think making that true in > the implementation is something that Blake wants to do eventually.) This seems > to not be true based on your comment #4, but I think we probably want to make > it more true rather than less true. If I understand you correctly, I would *love* to see this happening. IE6 is doing that, only one selection per top-level document. Mozilla instead, is currently making selections in sub-frames appear grayed out (disabled), which I find ugly. Is there a bug on this? I never dared to propose such a thing. I also would love to have a selection api that also can handle it when something is selected in input/textareas. Currently, they have their own .selectionStart/.selectionEnd/setSelectionRange methods, but that's really troublesome and doesn't handle multiple selection ranges. So I would like to have a hook on window.getSelection() somewhere that can tell me if there is something selected in the document, including textareas/inputs.

My intention in the WHATWG spec was to define APIs (based on the Firefox 1.5s APIs) that would return one selection for the text in a Window/Document, and one each <input> and one for each <textarea>. Thus each <iframe> could have its own selection, as could each text control, and those selections are all independent. That's actually what Firefox does now. This does not imply you have to actually *render* all these selections all the time. But you do need them in the underlying implementation because script will expect to be able to manipulate all these selections independently, mutating the underlying text.

Okay, so how about this: -- For each top-level window, only display the selection associated with focus. In particular, -- if a text control node is focused, then display its selection only, if any -- otherwise display the selection, if any, of the document containing the focused node I'm not sure how close to this we currently come. -- Have an API to determine which node (if any) is focused in a given document (ignoring whether the document's top-level window is focused or not). Does WHATWG have something for this? If not, we should borrow from IE if IE has something sane. Maybe you guys should all thrash out what what the overall focus/selection model and APIs should be in the context of WHATWG ... not in this bug.

(In reply to comment #19) > I'm not sure how close to this we currently come. 2 and 3 are already being done by Mozilla. 1 not, in that case you get a grayed out (disabled) selection. WHATWG already seems to have something specified for the focused node. For selection stuff, it seems to be going to do what Mozilla is doing currently (which I'm not entirely happy with, because it doesn't handle multiple selections in text inputs). > Maybe you guys should all thrash out what what the overall focus/selection > model and APIs should be in the context of WHATWG ... not in this bug. Yes, you're right, probably. The only thing is, you didn't like my patch, but that's basically what the bug is about, so I'm not sure what to do with this bug anymore. It seems like it is invalid to me, then.

Let's resolve this as invalid and work on having an API to determine the focused node.

The WHATWG "currentFocus" property sounds reasonable to me, FWIW.

Filed bug 337631 for supporting document.currentFocus.

*** Bug 357524 has been marked as a duplicate of this bug. ***

This always returns "null" on a textarea and always returns en object in any other HTML Element... Is it related to this bug ? window.getBrowser().contentWindow.getSelection().focusNode; Do there are a way to resolve it temporarly ?

If forgot to say it is a recent Bug that i do not encountered in the Firefox 1.5.7 Version.

(In reply to comment #25) > Do there are a way to resolve it temporarly ? No, as far as I can tell this bug means there's no way to tell the active form element in Firefox 2.0 without using handlers for each element (document.activeElement is only available in trunk).

Why is it "Status: RESOLVED INVALID". The activeElement or getSelection().focusNode still doesn't work.

On trunk?