Closed
Bug 380204
Opened 17 years ago
Closed 17 years ago
Enhance focus visibility for F6 focus cycling in ChatZilla
Categories
(Other Applications :: ChatZilla, defect)
Other Applications
ChatZilla
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: Gijs, Assigned: Gijs)
References
(Blocks 1 open bug)
Details
(Keywords: access, Whiteboard: [cz-0.9.79])
Attachments
(1 file, 3 obsolete files)
6.04 KB,
patch
|
bugzilla-mozilla-20000923
:
review+
|
Details | Diff | Splinter Review |
Currently you can barely distinguish a focused output window (tiny rectangle inside the browser viewport), and you can't at all see an empty tree is focused. Sometimes the caret in the input box is also gone for short periods of time. It would be good if we could figure out something to do about this, preferably without being too disturbing while still getting the point across better than the current status. Suggestions welcome. Two things I thought could do: - Style the "focused" state for the elements as having a thicker focus rectangle, if possible. I'm not sure how hard this is to do when considering high visibility themes etc. - Blink/Flash/Color border. I don't really like this suggestion and think it will be very disturbing, but if all else fails it's certainly technically possible.
Comment 1•17 years ago
|
||
2px solid outline (not border) on the userlist/chat area/input for 2s? Not sure on colour. If we only do it from out own F6 handler, I think this should fit into the informed-but-not-quite-annoying bracket.
Assignee | ||
Comment 2•17 years ago
|
||
That sounds like it would work. But now that I think of it, I seem to recall DOMI showing a red rectangle in a *really* weird spot (about 100-200 pixels off in both directions) when telling it to blink existing elements and exploring the tree. Not sure if that'll affect this as well. Try and see, I guess. Oh, and I agree on the informed but not quite annoying bracket, I guess :-)
Comment 3•17 years ago
|
||
My understanding of the issue is that DOMI's outlines are screwed up when done on things inside a new widget - i.e. a scrollable thing (or fixed position things, until fairly recently IIRC). CSS outlines may or may not be the same, I can't remember. I believe the outlines are right if they're only being done on the tree/browser elements, and not things inside, but if all else fails I would probably be quite happy with a <box> wrapper around each to put the outlines on.
Assignee | ||
Comment 4•17 years ago
|
||
This turns out to be harder than I thought... the outlines only show up on the bottom and right side of things, and even adding margins on the boxes I'm putting them on doesn't seem to help much :-\
Comment 5•17 years ago
|
||
That sounds like fun; I'd love to see a screenshot of that (and the CSS code).
Assignee | ||
Comment 6•17 years ago
|
||
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•17 years ago
|
||
Using padding instead of margins didn't really improve the situation. Using a 1 or 2px outline instead of 10px also didn't do the trick (and no, I wasn't actually planning to use 10px, but hey, I was trying to get things to show up... had to do something ;-) )
Comment 8•17 years ago
|
||
Heh, that's looking very much like it's just drawing over it with the child elements (in complete contradiction of the CSS spec). You might be able to use outline-offset to make it draw the outline going outwards rather than inwards (I can't remember which way it points, you can just try -5px and 5px values or look it up).
Assignee | ||
Comment 9•17 years ago
|
||
So this gets you a red border on the elements, with some fancy timeout stuff so it lasts a second after the last F6 press whatever the case (even if you press F6 a couple of times). I'm wondering whether we should make it also include escape though... and/or make it more robust so moving away using <tab> will cause it to go away immediately (onblur? is prolly really hard with the elements we're talking about, especially the browser(s)). This problem is way harder than I thought :-( Anyway, this works at least basically. Asking r? anyway.
Attachment #282128 -
Attachment is obsolete: true
Attachment #282129 -
Attachment is obsolete: true
Attachment #282322 -
Flags: review?(silver)
Comment 10•17 years ago
|
||
This looks good, but I'm thinking it needs some refinement on what borders are shown where. - Userlist: I think this should omit the left edge, symetrically to what the deck/display area does. - Userlist/display area: Need to swap which edge is missing when the userlist is on the right. - Input box: I'd like this to only be around the input box itself, and omiting the bottom border. I think we should be using a system colour instead of red, but I'm not sure what would be suitable.
Assignee | ||
Comment 11•17 years ago
|
||
This should include all the comments previously given. :-)
Attachment #282322 -
Attachment is obsolete: true
Attachment #283723 -
Flags: review?(silver)
Attachment #282322 -
Flags: review?(silver)
Assignee | ||
Comment 12•17 years ago
|
||
(In reply to comment #11) > Created an attachment (id=283723) [details] > Patch including James' suggestions > > This should include all the comments previously given. :-) > Oh, yeah, except for the system colour - but like James I'm not sure what would actually work...
Assignee | ||
Comment 13•17 years ago
|
||
So, James, I know you're really really busy these days, but it would be excellent to get a review on this, if at all possible. :-)
Comment 14•17 years ago
|
||
I put off review earlier this week because I wanted to look for a suitable system colour to use, as well as testing the changes myself. Considing the rest of Bugzilla, I don't think you have much reason to complain after less than a month waiting for review. :P I'll try to do it this evening, after getting home, or the weekend otherwise.
Comment 15•17 years ago
|
||
Comment on attachment 283723 [details] [diff] [review] Patch including James' suggestions r=silver with the colour changed to Highlight. Rather amusingly, changing the userlist side runs into bug 73586, meaning the empty gaps where the highlight goes don't update until you next hit F6, but that's not our bug, and is not likely to be very visible anyway.
Attachment #283723 -
Flags: review?(silver) → review+
Assignee | ||
Comment 16•17 years ago
|
||
Checking in mozilla/extensions/irc/xul/content/chatzilla.xul; /cvsroot/mozilla/extensions/irc/xul/content/chatzilla.xul,v <-- chatzilla.xul new revision: 1.70; previous revision: 1.69 done Checking in mozilla/extensions/irc/xul/content/static.js; /cvsroot/mozilla/extensions/irc/xul/content/static.js,v <-- static.js new revision: 1.247; previous revision: 1.246 done Checking in mozilla/extensions/irc/xul/skin/chatzilla.css; /cvsroot/mozilla/extensions/irc/xul/skin/chatzilla.css,v <-- chatzilla.css new revision: 1.39; previous revision: 1.38 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [cz-0.9.79]
You need to log in
before you can comment on or make changes to this bug.
Description
•