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.
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.
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 :-)
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.
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 :-\
That sounds like fun; I'd love to see a screenshot of that (and the CSS code).
Created attachment 282128 [details] Screenie of weirdo outline
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED
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 ;-) )
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).
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.
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.
Created attachment 283723 [details] [diff] [review] Patch including James' suggestions This should include all the comments previously given. :-)
(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...
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. :-)
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 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+
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
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.