904924 - Remove tab-clip-path-outer for the new tab button

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Matthew N. [:MattN]]

Attachment: v.1 - No new tab button clip-path

The new tab button's clip path seems to account for ~10% of TART frame interval differences on my XP single-core VM with HWA off.

We can probably remove the clip-path and do one of the following:
1) fix the layering of the button compared to the tabs
2) accept an incorrect hover/clickable area
3) use a rectangular pointer-event region (without clip-path) using another element.

I don't know how feasible each of these options are.

Comment 1

[Matthew N. [:MattN]]

Comment on attachment 789896 [details] [diff] [review]
v.1 - No new tab button clip-path

Actually, it seems like this patch has the same behaviour (for which area you can hover over) as background tabs so I think we can just land this.

This actually shows potentially large wins on ts_paint http://compare-talos.mattn.ca/index.html?oldRevs=d69fa7f94f40&newRev=2b3adc222e4c&submit=true

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 789896 [details] [diff] [review]
v.1 - No new tab button clip-path

Review of attachment 789896 [details] [diff] [review]:
-----------------------------------------------------------------

Tested it and it works good.

Comment 3

[Matthew N. [:MattN]]

https://hg.mozilla.org/projects/ux/rev/af9924226bb0

Comment 4

[:Gijs (he/him)]

Fab, as the British would say!

Have we looked at not adding clip paths to the tabs until after the animation finishes?

Comment 5

[Matthew N. [:MattN]]

(In reply to :Gijs Kruitbosch from comment #4)
> Have we looked at not adding clip paths to the tabs until after the
> animation finishes?

As discussed on IRC, the other uses of clip-path actually clip the background and gradients unlike this one which was only used for the pointer-events.

Comment 6

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/rev/af9924226bb0