379939 - [CSS] HTML Elements with -moz-user-focus:ignore are still focusable

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Daniel Kirsch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a5pre) Gecko/20070501

An input element with the style -moz-user-focus:ignore is still focusable. This worked in 1.7 but doesn't with 1.8 and 1.9.

We use this setting for a WYSIWYG GUI in a XULRunner application. It might be important for other projects like NVU as well.

The CSS3 property user-focus doesn't work either (doesn't seem to be implemented yet).

Reproducible: Always

Comment 1

[Daniel Kirsch]

Attachment: Simple testcase

Opening the testcase in Firefox 1.0 works as expected. Firefox 2.0 and current nightlies don't work.

Comment 2

[Daniel Kirsch]

The regression range:
Firefox-win32_2004_07_24 works
Firefox-win32_2004_07_26 doesn't work

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Maybe bug 250006?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #3)
> Maybe bug 250006?
> 

the patch in that bug seems to have moved lines:
-    if (ui->mUserFocus != NS_STYLE_USER_FOCUS_IGNORE &&
-        ui->mUserFocus != NS_STYLE_USER_FOCUS_NONE) {

Comment 5

[Daniel Kirsch]

Setting the "focusable" attribut on a XULElement (tab) doesnt seem to work too. Is this related or another bug?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

-moz-user-focus:ignore does seem to work with xul buttons for example.

(And this bug is about -moz-user-focus, not about xul's focusable attr)

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Aaronl, do you have any comments to this?

Comment 8

[Aaron Leventhal]

> -moz-user-focus:ignore does seem to work with xul buttons for example.

Hi Smaug, do you mean it doesn't work?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

hmm, I wonder what I meant :) I had some testcase, and I think with
XUL -moz-user-focus:ignore seemed to have some effect.

Comment 10

[Aaron Leventhal]

Reporter: we purposely don't support that property for HTML anymore, because it's not an official CSS property.

I have several questions:

Do you have a XUL testcase or are you only having this problem for HTML?

Also, there are two things one might want to do:
1) Remove it from the tab order, but still allow scripts and mouse clicks to focus  the element
2) Make it completely unfocusable by any means

Comment 11

[Aaron Leventhal]

I should add:

For #1, you can do this for HTML now with tabindex="-1", which also works in IE.

For #2, you can mark it disabled, or don't use a form control to render this information.

Comment 12

[Daniel Kirsch]

I currently don't have a XUL testcase. As far as I can see, it works for XUL elements.

But I need it to select a html:input element. This is a common task vor WYSIWYG html editors like NVU/Kompozer. With the current implementation, clicking on the input element causes the caret to blink in the element. When pressing the "delete" key the input element catches it and the GUI (XUL) didn't get informed.

Setting the tabindex to "-1" doesn't have the wanted effect. IMHO this should only work when setting the focus by using the tab key but not when clicking it and that's how it works. BTW. it only works when setting the attribute, not by setting the property.

Setting the disabled attribute causes the element to suppress the click event so the gui cannot catch it anymore to select the element.

I really wonder why this is not supported anymore and how NVU or other apps solved it.

Comment 13

[Aaron Leventhal]

> But I need it to select a html:input element. 
Okay.

> Setting the tabindex to "-1" doesn't have the wanted effect. IMHO this should
> only work when setting the focus by using the tab key but not when clicking it
> and that's how it works.
Sorry to be dumb. I don't understand exactly -- what do you mean?

> BTW. it only works when setting the attribute, not by
> setting the property.
Are you using |tabIndex| with intercaps? That should work.

> I really wonder why this is not supported anymore 
We chose to go with something that's implemented on more than one browser. The CSS3 user-focus property is no longer in the spec, unless that's changed back again.

> and how NVU or other apps solved it.
Not sure, by handling the focus event on the element? Can you try this?

If there's no other way to do what you need we can look at it again.

Comment 14

[Daniel Kirsch]

(In reply to comment #13)
> I don't understand exactly -- what do you mean?

I mean that the tabindex property only covers keyboard navigation and focusing. But it doesn't disable focusing the element with a click on an input field. But that's how an author will "select" the input field to move it around or change properties in a WYSIWYG environment.


> We chose to go with something that's implemented on more than one browser. The
> CSS3 user-focus property is no longer in the spec, unless that's changed back
> again.

Well, I still don't understand why this usefull feature is dropped. There are many non standard properties implemented. Disabling something that used to work in previous versions which isn't security related means to break some behaviours.


> Not sure, by handling the focus event on the element? Can you try this?

Yes, but that means to implement a focus handler for each input element as the focus event doesn't bubble and cannot be catched at document level (or I was at least unable to catch it). In my case the elements will be created dynamically (using DOM methods) and have different presentations where in "preview" presentation everything should work as usual but in "authoring" presentation focusing should be avoided. Using a CSS property was way easier. I just disabled to "authoring" stylesheed when in "preview" mode.


> If there's no other way to do what you need we can look at it again.

Using a CSS property would be great as it simplifies the process a lot. An ugly workaround would be to be able to catch the focus event at document level and call event.target.blur()

Comment 15

[Yury Semikhatsky]

On Windows disabled menuitems are also focusable unlike Mac and Linux. Would be nice to have them unfocusable on Windows as well.

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 17

[noitidart]

-moz-user-focus: ignore doenst work.

please see this example:

				<label>
    				<input type="checkbox" id="customAppButton" style="-moz-user-focus: ignore;">
    				<span>Custom App Button</span>
				</label>

Comment 18

[cscott]

Another use case: I have two panes in my UI, and use a css transform to move the appropriate one into view.  User focus is screwed up because FF still lets me tab to move the focus to an invisible pane.  I'd like to set '-moz-user-focus: ignore' to the out-of-sight panes with pure CSS.