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

NEW
Unassigned

Status

()

Core
Layout: Form Controls
10 years ago
2 years ago

People

(Reporter: Daniel Kirsch, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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
(Reporter)

Comment 1

10 years ago
Created attachment 263990 [details]
Simple testcase

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

Updated

10 years ago
Keywords: testcase
Version: unspecified → Trunk
(Reporter)

Comment 2

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

Comment 3

10 years ago
Maybe bug 250006?

Comment 4

10 years ago
(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) {

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 5

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

Comment 6

10 years ago
-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

10 years ago
Aaronl, do you have any comments to this?

Updated

10 years ago
Assignee: nobody → aaronleventhal

Comment 8

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

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

Comment 9

10 years ago
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

10 years ago
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

10 years ago
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.
(Reporter)

Comment 12

10 years ago
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

10 years ago
> 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.
Summary: [CSS] Elements with -moz-user-focus:ignore are still focusable → [CSS] HTML Elements with -moz-user-focus:ignore are still focusable
(Reporter)

Comment 14

10 years ago
(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

9 years ago
On Windows disabled menuitems are also focusable unlike Mac and Linux. Would be nice to have them unfocusable on Windows as well.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody

Comment 17

6 years ago
-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

5 years ago
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.
You need to log in before you can comment on or make changes to this bug.