328193 - Tab focus ring / outline not always complete - chrome elements interfere with outline

Status: RESOLVED WORKSFORME

(Firefox :: Theme, defect)

Description

[Wayne Woods]

Just a minor polish bug, but I'm surprised it hasn't been reported before...

In the Mac trunk builds, if you focus a tab so that the blue focus ring / outline appears, sometimes the ring is only partially drawn (or perhaps partially hidden?).

Sometimes it's only one side of the focus ring that is missing, sometimes it's one side and the top. I'll attach a screenshot next, to illustrate.

Sometimes you can reproduce this simply by switching between tabs. But at worst, this method seems to only produce a missing side to the focus outline.

A much more reliable method is to first put the mouse focus on a text box within a page. As expected, the tab focus outline disappears with the focus change. Then click on the tab again to focus it. Or click twice on another tab to focus that. The blue focus ring should appear around the tab, but you should notice that the top and one side of it are missing.

Mousing over tabs or bookmark toolbar buttons that are next to the missing focus outline restore the adjacent section of it.

This bug started between the 20050627 and 20050628 builds. I assume it's a result of the fix for bug 298799.

Comment 1

[Wayne Woods]

I presume this is yours, Asaf?

Comment 2

[Wayne Woods]

Looking further, it seems that the patch for bug 298799 only revealed an underlying problem. I don't believe it directly caused this bug.

It looks like the css "outline" property (and moz-outline, too) is often failing draw over the top of adjacent XUL elements. If the focus was already in the tab bar, then clicking on a tab seems to produce a better (but not perfect) result. If the focus was previously in some other container, such as the web page or location bar, then far less is drawn.

Is there any reason for the previous focus to affect the behaviour of the current focus?

I guess this wasn't obvious when border was used, because that property draws the border within defined boundaries for the tab (or forces those boundaries to accommodate it), so no overlap?

I've been trying to find a way to reproduce this using css in a web page, but so far no luck. Maybe the failure is only in XUL...

If you guys have any suggestions, I'm happy to keep looking.

Comment 3

[(not reading, please use [e-mail] instead)]

*** Bug 342904 has been marked as a duplicate of this bug. ***

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: screen shot from 1.5

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: screen shot from trunk

Comment 6

[Wayne Woods]

This bug occurs on the 1.5 branch too, but in a slightly different way to the trunk.

On the 1.5 branch, click on the content area and then back on the tab. The rhs of the focus ring will most likely be broken... as opposed to the trunk where it's most likely the top that has disappeared, and the sides appear thinner.

Actually, it behaved the same way as the branch in trunk builds up until, and including, 20060125. I'm willing to bet it changed because of the check-in for bug 317375, which caused other weird tab behaviour for a while.

So while the bug existed for some time before that check-in, maybe that info can help track it down.

Comment 7

[philippe (part-time)]

I see this happening with form controls as well, when using a customised forms.css to create a focussing ring on widgets.

with the following -minimal- code (add to your userContent.css)
input:focus,
select:focus {
	outline-style: solid !important;
	outline-width: 1.4pt !important;
	outline-color: -moz-mac-focusring !important;
	outline-offset:0;
}
This gives a focussing ring around widgets,  Safari/OS style

Sometimes the outline is displayed correctly, sometimes the are visible gaps, or missing the outline on one of the sides, similar what is shown in the attached screenshots on tabs.
I haven't been able to make a reduced test case that works consistently.

Comment 8

[Rob Campbell [:rc] (:robcee)]

Attachment: screen shot from 2.0b rc1

I'm seeing similar in windows with single tabs (highlighting is too wide) and the sides disappear on windows with lots of tabs in them (overflowed).

Comment 9

[Wayne Woods]

Interesting, so it does! ->All/All. I'm not sure what css you used, but I'll document what I did below.

STR:
1. In Firefox profile in Windows XP, create a chrome subfolder
2. Create a user.Chrome.css file in the folder, with the contents:
tab:focus {
  outline: 1.4pt solid;
  -moz-outline-radius-topleft: 50%;
  -moz-outline-radius-topright: 50%;
}
3. Restart Firefox and focus a tab

Three things that seem to be slightly different between the Mac and Windows versions of this bug, using the css I just mentioned:

1. Often the left hand side of the outline isn't drawn immediately (happens on both platforms), but in Windows, it IS drawn after a very brief (~0.5 s?) delay. On Mac, it wouldn't be drawn at all until the adjacent tab was hovered over, which seems to force a repaint. It looks like something on Windows forces a delayed repaint.
2. I can't get the tops of the outlines to appear at all on Windows. On Mac, if they're absent, then they can be made to appear by hovering over the bookmarks buttons. So this seems to force a repaint on Mac, but not Windows.
3. On Windows only, the tab close button seems to disrupt the outline.

Comment 10

[Wayne Woods]

The new Mac changes to tab outline (outline around tab text only... bug 333514) now make this bug pretty useless. However, it's still technically a bug... just one that's hidden unless you manually add the tab outline... same as with Windows. So I'll leave it open.

Comment 11

[Asa Dotzler [:asa]]

*** Bug 334046 has been marked as a duplicate of this bug. ***

Comment 12

[Dão Gottwald [:dao]]

Closing ancient bug.