Enhance focus visibility for F6 focus cycling in ChatZilla



12 years ago
11 years ago


(Reporter: Gijs, Assigned: Gijs)


(Blocks: 1 bug, {access})


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [cz-0.9.79])


(1 attachment, 3 obsolete attachments)



12 years ago
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.


12 years ago
Blocks: 370759

Comment 1

12 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.

Comment 2

12 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

12 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.

Comment 4

11 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

11 years ago
That sounds like fun; I'd love to see a screenshot of that (and the CSS code).

Comment 6

11 years ago
Created attachment 282128 [details]
Screenie of weirdo outline
Assignee: rginda → gijskruitbosch+bugs

Comment 7

11 years ago
Created attachment 282129 [details] [diff] [review]
Patch that was used for the screenie (not for checkin or review)

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

11 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).

Comment 9

11 years ago
Created attachment 282322 [details] [diff] [review]
Patch using transparent borders going red for a bit

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

11 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.

Comment 11

11 years ago
Created attachment 283723 [details] [diff] [review]
Patch including James' suggestions

This should include all the comments previously given. :-)
Attachment #282322 - Attachment is obsolete: true
Attachment #283723 - Flags: review?(silver)
Attachment #282322 - Flags: review?(silver)

Comment 12

11 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...

Comment 13

11 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

11 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

11 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+

Comment 16

11 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
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
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
Last Resolved: 11 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.