a) In editable dropdowns, the textbox would not repaint to non-focused state when it lost focus. The solution is to get rid of a hack. A consequence of this is that editable dropdown fields won't get the highlight, but that is a far less obvious regression than the focus light sticking around. b) In listboxes, scrolling will cause a tidbit of the focus light to disappear in the top border. Since listboxes aren't editable anyway they should not get the focus light, so prevent that. c) In textareas such as the ones on bugzilla, the caret is a little too close for comfort on the top border and will cause a part of it to disappear when you type. The solution is to add 1 to the top border to move the caret off the top. This is to cater for the most common themes; Clearlooks and Human derivatives.

(In reply to comment #0) > c) In textareas such as the ones on bugzilla, the caret is a little too close > for comfort on the top border and will cause a part of it to disappear when you > type. The solution is to add 1 to the top border to move the caret off the top. I'm not sure about this part. Should we be fixing the caret position instead?

(In reply to comment #1) > (In reply to comment #0) > > c) In textareas such as the ones on bugzilla, the caret is a little too close > > for comfort on the top border and will cause a part of it to disappear when you > > type. The solution is to add 1 to the top border to move the caret off the top. > > I'm not sure about this part. Should we be fixing the caret position instead? > I'll see what I can do, although the caret code is really messy and is making my head spin trying to understand it :(

You shouldn't need to look at the code. The question is, are we drawing the caret where GTK would draw it, or not?

It all depends. In most textboxes it is fine, but in the comments box on the attachment details page the caret is drawn way to close to the edge, so much so that it covers part of it. Yeah, this isn't the right fix because the search field on ign.com is also showing this problem. I'm not sure why the caret gets it right in some cases and not in others.

Make a reduced testcase and file a separate bug on that, and submit a new patch here with the rest of the changes.

Aha, I've found the cause. IGN is setting padding:0 on input {}, which includes the textbox. This overrides the value in forms.css, and causes the caret to be painted too close to the top of the border. So the fix is actually sort of correct after all, unless there is a way to specify minimum padding. Roc, any ideas on where to go from here?

Even a padding:0 <input> should not let the caret draw over the border of the textbox, so I think you should still file a separate bug on that.

On my theme, the glow is 1px thicker than the unfocused border, which is the one we measure when Gecko asks for the border widths. So I still think its widget/'s fault. Ideally I'd like to be able to pass a border value to Gecko that includes any focus border decoration.

Can you post a screenshot, preferably one that's zoomed in so I can see what you mean? Thanks!

This is what happens when padding is set to 0 on textboxes under Clearlooks and Clearlooks clones.

It looks like we're not actually drawing the caret into the glow, we're just failing to draw the glow when some area is invalidated that includes the glow but not the rest of the widget border. Or something like that. If so then this is not a caret issue. Try invalidating parts of the widget by dragging a small window, you may be able to reproduce the bug that way.

Roc you are absolutely right, I tried it and could reproduce the same problem. So now I have to clue where to go from here, I've never dealt with any code regarding invalidation.

One thing you can do is set up a simpler testcase that reliably reproduces the bug. ... e.g. have a small div positioned in just the right place with a button that you can click to make it visible/invisible. Then see if the native widget drawing code to draw the border is being called when you trigger the bug. If it is being called, you can check the dirty rect etc and try to figure out why it isn't drawing the glow properly. If it isn't being called (which seems more likely), set gDumpPaintList=1 in gdb while running and report what you get when the bug is triggered.

Argh, I can't reproduce it using that kind of testcase... I'll add some printf's in random places to see what is happening on reproducible sites.

OK, I can confirm that textboxes and their borders are indeed being repainted whenever they should be (letter is typed in, caret blinks/unblinks). Sorry Roc but I don't understand the rest of your comment :(

If the native theme drawing code is being called when the caret blinks, I guess you'll have to figure out why it isn't drawing the glow properly. I don't have any good guesses there.

My original suspicions were true, it was a Cairo bug. After the recent Cairo update I no longer see this.