313573 - focusedElement is <html:input> inside XUL <textbox> instead of <textbox> itself

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[TC]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

I was trying to keep the focus locked to a textbox with invalid value.  "this.focus();this.select()" doesn't work as documented.

So, I tried to keep the 'id' of element at focus and use the 'id' to set focus. But this workaround did not work either.

The problem is that: unlike the good element (button, checkbox), the textbox element does not provide its 'id' when it has the focus.

Please see attached XUL sample: focusID.xul


Reproducible: Always

Steps to Reproduce:
1.Open the focusID.xul
2.Select the button, its id displays 
3.Select the checkbox, its id displays
4.Select the textbox, its id is !empty!

Actual Results:  
The textbox's id is empty

Expected Results:  
The textbox's is is displayed

Comment 1

[TC]

Attachment: XUL file shows the id of textbox is not visible when it has the focus

Comment 2

[Sébastien Auger]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5

I am confirming this with today's build. This is a regression of the expected behaviour. Do you know the approximate regression date ? 

Comment 3

[Asa Dotzler [:asa]]

yes, we need a regression window here.

Comment 4

[Jesse Ruderman]

Attachment: better testcase

Looks like the <html:input> inside the <textbox> is reported as having focus.

Comment 5

[Jesse Ruderman]

I'm not convinced that this is a regression.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050817 Firefox/1.6a1
- Same.

Firefox 1.0.7
- Same for the textbox.
- I get errors when I click on the button or checkbox.

Comment 6

[Mike Schroepfer]

Until we confirm this is a regression and/or understand better the severity of this - removing from 1.5rc1 list.

Comment 7

[Phil Ringnalda (:philor)]

Certainly not a recent regression: I see the exact same behavior on both testcases in 20051024 and Firefox 0.8 (20040206).

Comment 8

[Martijn Wargers (dead)]

Well, not a regression, so removing regression keyword.
From:
http://www.xulplanet.com/references/xpcomref/ifaces/nsIWebBrowserFocus.html
"The currently focused nsDOMElement when the browser is active, or the last focused nsDOMElement when the browser is inactive."

Maybe this is a special case of bug 53007?
I'm not sure if this is a bug at all.

Comment 9

[Boris Zbarsky [:bzbarsky]]

This has nothing to do with XBL, really.  Certainly not with the core XBL impl.  The bug, if any, is either in the XUL api involved (command dispatcher, etc) or in the textbox binding.  The former needs documenting as to how it interacts with anonymous content in general; based on the results of that perhaps the latter should be modified.

Comment 10

[shutdown]

1.1  blakeross%telocity.com 2002-08-12 20:25   History quicksearch.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/widgets/textbox.xml&rev=1.1

Very old code that considers focusedElement == <input> case.

Comment 11

[Andrei Purice]

Marking this as Resolved > Incomplete since the last activity on this issue was 16 years ago and it might not be relevant anymore.
Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.