Open
Bug 379939
Opened 18 years ago
Updated 2 years ago
[CSS] HTML Elements with -moz-user-focus:ignore are still focusable
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
NEW
People
(Reporter: daniel, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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•18 years ago
|
||
Opening the testcase in Firefox 1.0 works as expected. Firefox 2.0 and current nightlies don't work.
Reporter | ||
Comment 2•18 years ago
|
||
The regression range:
Firefox-win32_2004_07_24 works
Firefox-win32_2004_07_26 doesn't work
Comment 3•18 years ago
|
||
Maybe bug 250006?
Comment 4•18 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•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 5•18 years ago
|
||
Setting the "focusable" attribut on a XULElement (tab) doesnt seem to work too. Is this related or another bug?
Comment 6•18 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•18 years ago
|
||
Aaronl, do you have any comments to this?
Updated•17 years ago
|
Assignee: nobody → aaronleventhal
Comment 8•17 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•17 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•17 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•17 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•17 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•17 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•17 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•16 years ago
|
||
On Windows disabled menuitems are also focusable unlike Mac and Linux. Would be nice to have them unfocusable on Windows as well.
Comment 16•15 years ago
|
||
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Comment 17•13 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•12 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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•