Richer focus model like IE

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
--
enhancement
13 years ago
4 years ago

People

(Reporter: jdperlow, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME -- see also bug 296469)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

IE has a richer focus/activation model than Firefox. IE differentiates between
focus and activation such that it is possible to set an element as active
without affecting whether the browser is active. These are exposed in IE with
document.activeElement, HTMLElement.setActive(), onBeforeActivate, onActivate,
onBeforeDeactivate, and onDeactivate.

Reproducible: Always

Comment 1

13 years ago
I'm working on a new product that will have a lot of usage. It works well in IE
and I'd like it to work at least as well in Mozilla. One of the things blocking
this is a richer focus model, so I'm hoping we can improve this for FF1.1
Flags: blocking-aviary1.1+

Updated

13 years ago
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
Whiteboard: DUPEME
kcoleman, timeless didn't bother saying it, but please don't set blocking flags
to +, instead nominate by setting to ?.

This may be a dup; it may be worth doing.  Not much will happen without the
right people cc'd on it.  I'll confirm it on spec.

/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hrm.. 'active' is a very confusing term here. In mozilla we use it to refer to
the action of activating an object, such as clicking a link or pressing a button.

Seems like IE means it to mean the currently focused node within a document.
I.e. the difference between calling focus() and setActive() is that the former
focues the document, whereas the latter doesn't.
There is no way whatever we do here could happen for 1.8 in any case, as far as
I can tell... (quite apart from the lack of a clear and thorough description of
what is being requested). 

Comment 5

13 years ago
Microsofts documentation on this:

activeElement Property:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/activeelement.asp

setActive Method:
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/setactive.asp

Events (with links to the other events mentioned in comment 0):
http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeactivate.asp

Updated

13 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Whiteboard: DUPEME → DUPEME -- see also bug 296469

Comment 6

12 years ago
See also bug 307933, "JavaScript focus changes in background tabs are ignored instead of confined".

Updated

12 years ago
Depends on: 337631

Updated

12 years ago
Depends on: 296469

Updated

12 years ago
Depends on: 343642

Comment 7

11 years ago
Should this bug be blocked by

Bugzilla Bug 220900 Focus breaks, cut/copy/paste and other focus-dependent tasks broken
No

Updated

11 years ago
Blocks: 164421
> IE differentiates between focus and activation such that it is possible to set 
> an element as active without affecting whether the browser is active.

It shouldn't be possible to affect whether the browser is active. So the existing methods should be enough. No?


> These are exposed in IE with document.activeElement,

I've added that to DOM5 HTML.


> HTMLElement.setActive(), onBeforeActivate, onActivate, onBeforeDeactivate, and 
> onDeactivate.

I don't really see the point of these given the restriction that focusing can't affect the browser itself.

Updated

10 years ago
Depends on: 402680

Updated

10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.