Closed Bug 54105 Opened 24 years ago Closed 24 years ago

Major css/xbl focus issues

Categories

(SeaMonkey :: Themes, defect, P2)

Product:
SeaMonkey
Component:
Themes
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: hangas, Assigned: hewitt)

References

Details

(Whiteboard: [nsbeta3-][rtm++])

Attachments

(1 file)

path for bug, r=andreww, a=ben
58.71 KB, text/plain
Details 
We have a number of issues with focus in our product that needs to be resolved in 
css and xbl:
1) Certain xul elements can receive focus even though they should not.  Examples 
include spring, tree columns, static text fields, etc.  These need to be set to 
user-focus: ignore;
2) Buttons and menulists need to stretch to accomodate the text size differences 
between Windows Mac and Linux, so that our focus rings will draw correctly around 
the widgets.
3) Radio buttons need to be made focusable in Modern.
Marking nsbeta3+ since this makes the product very difficult to use from the 
keyboard.  Joe has these fixes in his local tree.
Assignee: hangas → hewitt
Keywords: nsbeta3, rtm
Priority: P3 → P2
Whiteboard: nsbeta3+
that should be -moz-user-focus
Blocks: 18575
*** Bug 54328 has been marked as a duplicate of this bug. ***
Bug 54328 (dup) opened today addressed the subject of tabbing around a dialog.  
Anyone who's tried this will notice it's darn near impossible.  That's because 
when you hit tab, the focus is given to the next element in the tree (in pre-
order) whose -moz-user-focus is set to normal.  Currently, waaaay too many 
elements are set to normal.

I see no reason why spring, text, or treecol, for example, should be set to 
normal.  When you hit tab and the focus disappears, odds are that's because a 
spring has taken the focus.  Since XBL widgets have lots of spring and text 
elements, the focus is nearly always buried within them.  Here's a list of xul 
elements I'd like to see set to -moz-user-focus: ignore (that aren't already 
set to ignore in xpfe/global/resources/content/xul.css)

spring,box,titledbox,title,text,html,separator,
treecol,treecolgroup,treerow,treeitem,treecell, 
grid,columns,column,rows,row,
tabcontrol,tabbbox,tabpanel,
deck,stack,iframe

I may be missing a few tags, and perhaps someone may disagree with some of the 
above tags, so let me know... fixing this is crucial to making it possible to 
make the tab key useful again.
Status: NEW → ASSIGNED
nsbeta3-, rtm++
Whiteboard: nsbeta3+ → [nsbeta3-][rtm++]
I'm slightly puzzled, when I used the dialog in classic, I didn't experience 
these problems.

* I think you meant tabbox not tabbbox. Just make sure that users can navigate 
<tab>s correctly.
* trees relate to bookmarks, ftp, mail/news folders and addressbooks.... Users 
need to be able to walk through those too. I think that means that treerow must 
be able to accept focus.
Whiteboard: [nsbeta3-][rtm++] → nsbeta3+
Sorry collision mesed up.
Whiteboard: nsbeta3+ → [nsbeta3-][rtm++]
The default value of user-focus is none.  Perhaps this became busted when 
the property was renamed.

Most elements do not specify a user-focus, and therefore have a user-focus of 
none.  This means they do not take focus and they do not receive a tab, but they 
do cause a blur when clicked on.

Using user-focus ignore is incorrect, since ignore is a special value that 
indicates the element does not even cause a blur when clicked on.  Only certain 
special elements (like menupopups and scrollbars) should have this value.  Most 
UI elements should have user-focus values of none, and this is supposed to be 
the default.

We should chat about this and maybe construct a test case to see if the default 
value is wrong now or something.

One would think that treerow should accept focus, but actually it should not.  
tree accepts the focus.  On windows tree/table controls, you can't tab between 
rows.  Hitting tab leaves the tree/table element completely.  The tricky thing 
is that the row seems to be focused since it has a focus outline drawn around 
it, but it's the tree/table itself that actually has focus.
timeless, the reason the problem is not as obvious in classic is probably 
because classic widgets don't have as many springs within their anonymous 
content as modern.  Modern is image based and so the widgets need more 
boxes/springs to hold the images, and the focus is getting lost on these 
boxes/springs as you tab around.
There should already be rules in xul.css to set user-focus to none on all the 
inner tree tags (like treechildren and treerow).  If you're a tag that's always 
used as a child of a focusable object (e.g., a tag inside a tree), then ignore 
and none are actually interchangable.


*** Bug 54327 has been marked as a duplicate of this bug. ***
The bug here is in the way tabbing walks the frames.  Certain frames (like 
buttons, menuitems, and treecells) are all supposed to prevent events from 
getting inside them by default, and this works for mouse-related focus.  Tabbing 
isn't checking for this, though, and so tabbing incorrectly moves inside these 
frames.

I don't believe this is a style rule issue.  I think it's a tabbing bug.


To clarify something I said earlier, user-focus is actually inherited when 
unspecified, so everything inside a focusable button will also be focusable 
(e.g., have user-focus of normal).  Trying to fix this in CSS doesn't scale.  
Anything could be inside that button.  Writing a rule like button > * would be 
terribly inefficient but would fix the problem.  The best solution IMO is just 
to make sure that tabbing knows about the special XUL frames that hide their 
innards from the world: these include <checkbox>, <radio>, <tab>, <button>, 
<treecell>, etc. etc.  

If the tabbing code is patched, I expect most of the problems will go away, 
since we already have rules fixing things like treerows and treeitems and 
treechildren and menus etc. etc.

I think this should come my way.  Reassign if you agree.



Can we get some of the basic focus problems in the modern skin fixed for beta3? 

The main ones that are problems for me are that toolbar buttons take focus, which 

completely breaks the composer (and hence HTML mail compose) formatting toolbar -

- it's impossible to type, click the bold button, and continue typing in bold. 

You have to click back in the content area to focus it, which resets the current 

style. I'm gonna request nsbeta3++ for a partial fix.


Simon, I checked in a fix yesterday for the issue you are describing.  See bug 
#53735
After discussing this with Ben, I've concluded that the applicability of "none" 
versus "ignore" is sort of subjective.  On native chrome in Windows and Mac, 
clicking the background _does not_ cause the focused widget to lose focus.  
However, on a web page, clicking the background _does_ caue the focused widget 
to lose focus. I would think that XUL would seek to emulate chrome more than an 
html document, so it would seem that "ignore" should be the default value for -
moz-user-focus. However, as you said, due to inheritance of "normal" in 
XBL'ified widgets, this wouldn't completely solve the problem.  Still I think 
it should be done anyway.
Maybe we should just add:

* {
  -moz-user-focus: ignore;
}

to xul.css

*** Bug 54284 has been marked as a duplicate of this bug. ***
*** Bug 53325 has been marked as a duplicate of this bug. ***
*** Bug 52220 has been marked as a duplicate of this bug. ***
*** Bug 54547 has been marked as a duplicate of this bug. ***

    
    

    
  
This is now fixed on the branch.  Trunk landing coming soon.

    
    

    
  
seen on builds:
windows commercial trunk build 2000-10-05-06-M18
linux commercial branch build 2000-10-05-09-MN6
linux commercila trunk build 2000-10-05-06-M18


    
    

    
  
Fixed in trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Reopening bug, checkin left Mac buttons and menulists far too large.  Joe needs 
to checkin the fix.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Now fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
verified for all platforms (2000-10-10-10-MN6).
Status: RESOLVED → VERIFIED

    
    

    
  
Marking verified on all platforms
Windows (2001-01-02-21-Mtrunk)
Linux (2001-01-03-08-Mtrunk)
Mac (2001-01-02-08-Mtrunk)
Product: Core → SeaMonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: