Closed Bug 402680 Opened 18 years ago Closed 18 years ago

document.activeElement returns wrong node

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: smaug)

References

Details

(Keywords: testcase)

Attachments

(3 files, 1 obsolete file)

Attached file Testcase
Steps to reproduce: 1. Run testcase 2. Dismiss alert dialog saying "activeElement is [object HTMLHtmlElement]" 3. View source Note that the focus on the input element is set using window.onload. The alert comes before the window.onload. It should alert null, since the the window.onload has not triggered yet. IE alerts null.
This bug is also visible using a timer (3 seconds in this case) to set the focus on the text field.
http://www.whatwg.org/specs/web-apps/current-work/#activeelement http://www.whatwg.org/specs/web-apps/current-work/#the-body0 I think we want to return null when there is no body (yet). That is what html5 defines and that is what IE seems to do here. Hixie also suggested that.
Attached patch proposed patch (obsolete) — Splinter Review
.activeElement is a new feature in 1.9, so better to ship it with more compliance with IE.
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #287685 - Flags: superreview?(bzbarsky)
Attachment #287685 - Flags: review?(bzbarsky)
That doesn't make much sense for non-HTML documents, imo. Please do read the discussion in the bug that checked in this code...
I did, and comment 5 there was really the only one commenting about this. It doesn't make much sense to return null with htmldocuments and root element with non-html-documents. .activeElement is IEism, so IMO, we should work as closely as possible as IE. We could also close this as wontfix, but perhaps need to document somewhere that we don't follow html5 and work a bit different way than IE. Though I could also try to change HTML5 to follow gecko's current behavior.
> It doesn't make much sense to return null with htmldocuments and root element > with non-html-documents. Why not? We do special things like that with body all over. I'm perfectly happy to do just that.
I don't like non-html-documents working in a different way than html documents, but in this case I can perhaps blame IR :p
Attachment #287685 - Attachment is obsolete: true
Attachment #287693 - Flags: superreview?(bzbarsky)
Attachment #287693 - Flags: review?(bzbarsky)
Attachment #287685 - Flags: superreview?(bzbarsky)
Attachment #287685 - Flags: review?(bzbarsky)
(In reply to comment #7) > I can perhaps blame IR :p er, IE.
Comment on attachment 287693 [details] [diff] [review] return null only with html documents This I buy. Check in some testcases, please!
Attachment #287693 - Flags: superreview?(bzbarsky)
Attachment #287693 - Flags: superreview+
Attachment #287693 - Flags: review?(bzbarsky)
Attachment #287693 - Flags: review+
Comment on attachment 287693 [details] [diff] [review] return null only with html documents I'll check in some mochitests if I get approval.
Attachment #287693 - Flags: approval1.9?
Attachment #287693 - Flags: approval1.9? → approval1.9+
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Verified fixed with build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007111312 Minefield/3.0b2pre
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: