+++ 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.

I can confirm this bug affects on Debian, Ubuntu, and Linux Mint. Will the fix cover these platforms?

Yes, this is for all platforms.