Focus ring on native-styled tab is cut off at right

RESOLVED FIXED in mozilla1.9.2a1

Status

()

RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: stefanh, Assigned: mstange)

Tracking

Trunk
mozilla1.9.2a1
x86
Mac OS X
Points:
---
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

10 years ago
Created attachment 354605 [details]
Testcase

(Minefield trunk/1.9.1, Mac OS 10.5.6)

STR:

1) Load testcase
2) Hit the "Focus first tab" button
3) Look at the focus ring

Note: Focus ring on rightmost tab looks ok (you can get there by clicking on the tab once you have focus on the first tab).
Flags: blocking1.9.1?
(Assignee)

Comment 1

10 years ago
Is there a way to focus tabs other than calling .focus()?

I tried to fix this bug by setting position:relative on the selected tab, but that seems to break the frame order... bug 351238?
(Reporter)

Comment 2

10 years ago
(In reply to comment #1)
> Is there a way to focus tabs other than calling .focus()?

Hmm, I don't know. I noticed it because comm-central/source/suite/browser/pageinfo/pageInfo.xul focus the General tab upon onload with .focus() in comm-central/source/suite/browser/pageinfo/pageInfo.js#341.

I'm not saying this should be fixed because of that, but I can imagine that a bunch of other apps/extensions would want to do (or does) something similar. It feels like a "natural" way to focus a tab under certain circumstances.

> I tried to fix this bug by setting position:relative on the selected tab, but
> that seems to break the frame order... bug 351238?

Hmm, comments seems to indicate that bug is wfm? If there is no reasonable way to fix this, maybe we should make it so the focus ring doesn't appear at all?

Comment 3

10 years ago
I don't think I see this bug, can we get a screenshot attached here?
Assignee: joshmoz → mstange
Created attachment 355255 [details]
Screenshot of testcase

Screenshot on my trunk build from 20090101.
(Assignee)

Comment 5

10 years ago
tab:focus {
  opacity: 0.99;
}

might work.
(Assignee)

Comment 6

10 years ago
Created attachment 355822 [details] [diff] [review]
fix

It does work.
Attachment #355822 - Flags: review?(dao)
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED

Comment 7

10 years ago
(In reply to comment #5)
> tab:focus {
>   opacity: 0.99;
> }
> 
> might work.

Looks like a hack to me. What's the underlying problem here?
(Assignee)

Comment 8

10 years ago
The focus ring extend's beyond the focused tab's rect (it's in the overflow area), but it's partly hidden by the tab right next to it. The right tab is on top of it because it's later in the document.
So we need to manipulate the natural stacking order - the most natural way to do that is (to me) using position:relative, but that fails spectacularly. Setting opacity is the other way I know of that changes the stacking order.
(Assignee)

Comment 9

10 years ago
The focus ring extend's beyond the focused tab's rect (it's in the overflow area), but it's partly hidden by the tab right next to it. The right tab is on top of it because it's later in the document.
So we need to manipulate the natural stacking order - the most natural way to do that is (to me) using position:relative, but that fails spectacularly. Setting opacity is the other way I know of that changes the stacking order.
(Assignee)

Comment 10

10 years ago
Created attachment 355841 [details]
screenshot with position:relative

This is what happens when I set position:relative on the focused tab - something with the frame order goes wrong. It looks like the flexed centering spacer and the focused tab swap places.
looks like position:relative is screwing up XUL. That might be easy to fix. Reduced testcase?

Comment 12

10 years ago
Would like a fix but this bug isn't serious enough to block on.
Flags: blocking1.9.1? → blocking1.9.1-
(In reply to comment #9)
> Setting opacity is the other way I know of that changes the stacking order.

Does the CSS spec say that or is it a Gecko quirk?
Is a 1% transparency so faint that it's definitely not visible? I'm thinking of the selected tabbrowser tab which would be subject to this change, and which is supposed to connect with the above toolbar.
(Assignee)

Comment 16

10 years ago
(In reply to comment #15)
Oh, good thinking. I've just checked the tab background (#969696); the RGB values that end up on the screen haven't changed with the opacity, so it's definitely not visible.

(In reply to comment #11)
> looks like position:relative is screwing up XUL. That might be easy to fix.
> Reduced testcase?

I'll try to make one tomorrow.

Updated

10 years ago
Attachment #355822 - Flags: review?(dao)
Comment on attachment 355822 [details] [diff] [review]
fix

waiting for position:relative testcase
(Assignee)

Comment 18

10 years ago
Created attachment 365446 [details] [diff] [review]
fix with position:relative

The problem with position:relative seems to have been fixed by bug 307394.
Attachment #355822 - Attachment is obsolete: true
Attachment #355841 - Attachment is obsolete: true
Attachment #365446 - Flags: review?(dao)

Updated

10 years ago
Attachment #365446 - Flags: review?(dao) → review+
(Assignee)

Comment 19

10 years ago
pushed: http://hg.mozilla.org/mozilla-central/rev/3615bdf56262
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.