Bug 995733 (australis-tabs-v2)

Make Australis tabs scale and connect with the nav-bar better

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
5 years ago
7 months ago

People

(Reporter: MattN, Unassigned)

Tracking

(Depends on 1 bug, Blocks 3 bugs)

unspecified
Points:
8
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Australis:M-])

+++ This bug was initially created as a clone of Bug #946987 +++

With proper platform support (both in terms of bug fixes and performance), we should be able to make the tabs nicer visually and more maintainable. This bug is basically to track a more ideal implementation of Australis tabs given what we have learned during the process and without constraining ourselves by platform limitations under a time crunch.

The nav-bar top border (at least on Windows) is implemented as a linear gradient from the bottom of the tabs toolbar instead of as a proper border. This leads to incorrect snapping behaviour in relation to the tab curve pseudo elements and the nav-bar's highlight (a box-shadow on Windows). I believe this is partly why the problem is worse on Windows. I believe it's non-obvious to layout that it should snap a line drawn as a vertical gradient to an offset of a pseudo element in a positioned tab.
A somewhat dirty hack if the changes below don't fix this may be to have the selected tab draw the border line across the whole window (e.g. via a pseudo element) but there is a risk of this causing repaints of a much larger area than needed (e.g. the whole nav-bar). A new CSS feature to be able to cut an area, the nav-bar border+highlight in this case, out of an element painted behind it could also help. I haven't thought through how this would work though.

Right now (since bug 921038) the clip-path on the ::before curve pseudo elements is only used for clipping the theme background with LWT. We previously had it affecting the pointer-events for the small tail starting from half way through the (selected tab's?) curve. If we either (a) continue being fine with a rectangular pointer-event region or (b) use a pseudo-element just for this small triangle-like shape, and we have proper SVG image cache invalidation (e.g. bug 940625 and likewise for some other invalidations), we should be able to flatten the current pseudo-elements into a single SVG layer and then use border-image (depends on bug 619500) or multiple background-images (ideally together on .tab-background for optimal snapping, otherwise on the three .tab-background-* children) to achieve scalable tabs with (likely) better snapping behaviour/seams and with better alignment between the stroke & fill (bug 879679).

== Some key issues to keep in mind (in order to fail quickly if necessary) ==
* LWT are special in that we need a way to cover up the nav-bar top-border and highlight at the bottom of the selected tab. We can probably be smarter about only clipping the header image for the minimal vertical pixels required. This will probably remain a more complex special case unless we also look again at moving the border to the bottom of the tabstrip children except under the selected tab though this seemed fragile in the past.
* Snapping and rounding issues should be tested for early on. I would recommend developing with 1.25dppx on Windows with and without the menubar to see the effects of snapping and rounding.
* Performance -  While this more ideal solution shouldn't abort at the first signs of Talos regressions IMO, it will require coordination with layout/gfx teams in order to see which performance issues are worthwhile to fix in the platform. IMO we should block on those fixes where they were deemed worthwhile unless there is an alternative without downsides. Platform workarounds are the main issue that got us into our current tab implementation.

== Alternative solutions ==
* border-image with multiple image sets for each supported dppx.
  * See bug 946987 and how this may require changes to tab shape too so that
    the image dimensions don't require fractional pixels. This is not nice to 
    maintain and doesn't scale with the tab size e.g. with larger fonts.
* Implement the tab shape with <canvas> to match the system and lightweight theme and then reference that image from the tab via border/background-image
  * This may be too slow on firstrun (with an empty cache) and upon theme 
    changes when we have to redraw the canvas. It's also breaks the separation 
    between themes and content and is harder to maintain than using SVG IMO.
* Fully-native tabs drawn at the widget/gfx level e.g. with -moz-appearance:tab
  * Possibly requires an separate implementation for each platform and system 
    theme in a way which is less maintainable than using SVG and CSS.
  * I'm unsure how hard it is to go from UI designs in an image editor to 
    efficient native code drawing the shape.
  * This is not an area where the current theme developers have experience 
    AFAIK.
Flags: firefox-backlog?
Flags: firefox-backlog? → firefox-backlog+
Summary: Make Australis tabs scale and connect with the nav-bar better → [UX] Make Australis tabs scale and connect with the nav-bar better
Whiteboard: [Australis:M-] → [Australis:M-] [ux] p=0
Summary: [UX] Make Australis tabs scale and connect with the nav-bar better → Make Australis tabs scale and connect with the nav-bar better
Whiteboard: [Australis:M-] [ux] p=0 → [Australis:M-] p=0
Whiteboard: [Australis:M-] p=0 → [Australis:M-] p=8
Blocks: 1016543

Comment 1

5 years ago
I can confirm this bug affects on Debian, Ubuntu, and Linux Mint. Will the fix cover these platforms?
Yes, this is for all platforms.
Blocks: 1023511
No longer blocks: 1016543
Points: --- → 8
Whiteboard: [Australis:M-] p=8 → [Australis:M-]
Duplicate of this bug: 1169955
Depends on: 1264809
Blocks: 1271838
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.