Had to do some hacky stuff to make this work right since the tabs currently aren't overlapping the navBar. This will require whatever solution is worked out in bug 858089. Assets are included in the patch though.

Thanks Stephen! I think we can just do the image additions in this bug and fix the rest in bug 858089 for all platforms.

Stephen: Could you make tab-stroke-*@2x.png images that only have stroke and inner highlight (no fill) like on other platforms? See also: bug 858089 comment 4 point 3 for the regular DPI and Linux images. I'm considering landing the tab-background-*@2x.png images first so there is some progress here although it would lead to 2 small patches then.

Since we already have the images for background tabs, I'm would like this review and landed since I expect the updated stroke images will take some time. The background-size was already set to 100% for the height to allow the images to stretch when large fonts are used. I tested this in regular and HiDPI mode on 10.7.

Comment on attachment 750645 [details] [diff] [review] BG v.1 Image swap for HiDPI background tabs Review of attachment 750645 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for working on this. :) We need to add the HiDPI images to the preloading hack block in browser/themes/shared/tabs.inc.css. The HiDPI block should be wrapped in @media (min-resolution...

(In reply to Frank Yan (:fryn) from comment #6) > We need to add the HiDPI images to the preloading hack block in > browser/themes/shared/tabs.inc.css. Good catch. I added that hack in the same block so that we don't try to reference non-existent images on Windows with Hi-DPI.

Thanks for the images. Could you also provide non-HiDPI versions of tab-stroke-*.png so they get the tweaks you made so they connect with the nav-bar better. I think you said somewhere that the Windows ones can be used but the stroke colour is different. This won't block the bug but it would be good to have parity between HiDPI and non-HiDPI.

Comment on attachment 750672 [details] [diff] [review] BG v.2 Image swap for HiDPI background tabs with preloading https://hg.mozilla.org/projects/ux/rev/10dbf4ffe7ab

This switches back to background-image from content: url(…) because I couldn't figure out a way to get the generated content to not show at double the size while still stretching with taller tabs.

Comment on attachment 754077 [details] [diff] [review] FG v.1 Foreground tabs and separators Review of attachment 754077 [details] [diff] [review]: ----------------------------------------------------------------- I don't have a HiDPI display to test this on for OSX, but everything in here looks reasonable.

(In reply to Mike Conley (:mconley) from comment #13) > I don't have a HiDPI display to test this on for OSX, but everything in here > looks reasonable. Thanks. I also don't have a HiDPI display but you can force HiDPI on any display with Quartz Debug: http://www.mactrast.com/2013/01/how-to-enable-retina-graphics-on-a-non-retina-mac/

Comment on attachment 754077 [details] [diff] [review] FG v.1 Foreground tabs and separators Yeah, it seems I was wrong and there isn't a way to get this to behave correctly for hidpi. At least I haven't found one, either. r=me, although have you checked this behaves correctly when large fonts etc. are used on Windows? :-)

(In reply to :Gijs Kruitbosch from comment #15) > Comment on attachment 754077 [details] [diff] [review] > FG v.1 Foreground tabs and separators > > Yeah, it seems I was wrong and there isn't a way to get this to behave > correctly for hidpi. At least I haven't found one, either. r=me, although > have you checked this behaves correctly when large fonts etc. are used on > Windows? :-) PS: please do a try build against windows mochitests to see if this regresses the a11y tests that check for the accessibles exposed by <tab>s. I suspect you may need to revert the changes made by bug 874051 (for the best, really)

(In reply to :Gijs Kruitbosch from comment #15) > have you checked this behaves correctly when large fonts etc. are used on > Windows? :-) It works fine with Windows. Screenshot attached.

(In reply to :Gijs Kruitbosch from comment #16) > (In reply to :Gijs Kruitbosch from comment #15) > > Comment on attachment 754077 [details] [diff] [review] > > FG v.1 Foreground tabs and separators > > > > Yeah, it seems I was wrong and there isn't a way to get this to behave > > correctly for hidpi. At least I haven't found one, either. r=me, although > > have you checked this behaves correctly when large fonts etc. are used on > > Windows? :-) > > PS: please do a try build against windows mochitests to see if this > regresses the a11y tests that check for the accessibles exposed by <tab>s. I > suspect you may need to revert the changes made by bug 874051 (for the best, > really) I did a local test and indeed I needed to backout 874051 (9443ce3837d5). Backout 874051: https://hg.mozilla.org/projects/ux/rev/727658cf86e0 Land FG tabs: https://hg.mozilla.org/projects/ux/rev/aeed857bac21

will there be hidpi (1.25, 1.5) australis tabs for Windows? 1.25 and 1.5 (and 2.0) are the default scaling factors on desktop (vs 1, 1.4 and 1.8 on "metro" or Windows 8 Store Apps as they call now)

https://hg.mozilla.org/mozilla-central/rev/10dbf4ffe7ab https://hg.mozilla.org/mozilla-central/rev/aeed857bac21

(In reply to henryfhchan from comment #19) > will there be hidpi (1.25, 1.5) australis tabs for Windows? 1.25 and 1.5 > (and 2.0) are the default scaling factors on desktop (vs 1, 1.4 and 1.8 on > "metro" or Windows 8 Store Apps as they call now) The work for HiDPI support for (non-Metro) Windows is being tracked in bug 820679.