Jim, Can you mentor/take this ?

Comment on attachment 8608917 [details] [diff] [review] Patch Review of attachment 8608917 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the additional whitespace cleanup.

Comment on attachment 8608917 [details] [diff] [review] Patch Approval Request Comment [Feature/regressing bug #]: Windows 10 theme support [User impact if declined]: Will ease up uplifting future Windows 10 theme work [Describe test coverage new/current, TreeHerder]: Baked on m-c, no regressions so far [Risks and why]: Very low, small patch [String/UUID change made/needed]: none

This bug also fixes bug 1158298.

Comment on attachment 8608917 [details] [diff] [review] Patch [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: User impact if declined: ESR users on Windows 10 will see bug 1158298 (unreadable background tabs) Fix Landed on Version: 41 Risk to taking this patch (and alternatives if risky): Low String or UUID changes made by this patch: none See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

If we want this for ESR, the first patch from Bug 1061604 will need to be uplifted as well, otherwise this patch will not work.

[Tracking Requested - why for this release]: Fixes bug 1158298 (unreadable background tabs on Windows 10), we'll definitively want this before the Windows 10 release (End of July). As far as I know, next ESR (45) is in 2016 (after Windows 10 launch), so this is worth fixing for ESR.

(In reply to Tim Nguyen [:ntim] from comment #11) > [Tracking Requested - why for this release]: Fixes bug 1158298 (unreadable > background tabs on Windows 10), we'll definitively want this before the > Windows 10 release (End of July). As far as I know, next ESR (45) is in 2016 > (after Windows 10 launch), so this is worth fixing for ESR. FWIW, I don't think this makes sense. ESR users are on a slow update scheme for Firefox, I would be very surprised if they would update to win10 as soon as it's available. It's much more likely that they wait (potentially a very long time). These are the kind of companies who are sometimes only just moving away from XP to Windows 7 this year. Maybe some will already have win8, but I think it extremely unlikely any of them will be rushing to upgrade to windows 10. For the same reason, I don't think we need to hurry to get this stuff into ESR38.

(In reply to :Gijs Kruitbosch from comment #12) > (In reply to Tim Nguyen [:ntim] from comment #11) > > [Tracking Requested - why for this release]: Fixes bug 1158298 (unreadable > > background tabs on Windows 10), we'll definitively want this before the > > Windows 10 release (End of July). As far as I know, next ESR (45) is in 2016 > > (after Windows 10 launch), so this is worth fixing for ESR. > > FWIW, I don't think this makes sense. ESR users are on a slow update scheme > for Firefox, I would be very surprised if they would update to win10 as soon > as it's available. It's much more likely that they wait (potentially a very > long time). These are the kind of companies who are sometimes only just > moving away from XP to Windows 7 this year. Maybe some will already have > win8, but I think it extremely unlikely any of them will be rushing to > upgrade to windows 10. For the same reason, I don't think we need to hurry > to get this stuff into ESR38. According to the release schedule, ESR 45 is coming in March 2016. I'm pretty sure there will be some Win10 ESR users within the 6 months separating the Windows 10 release and ESR 45. 6 months are not negligible, and is enough time for companies/schools to upgrade to Windows 10. Having unreadable text on background tabs is a pretty bad bug that pretty much makes Firefox unusable (you'll have #fff text on a #fff titlebar background).

We care about Windows10, tracking.

Comment on attachment 8608917 [details] [diff] [review] Patch We care about Windows 10, taking it.

We should absolutely uplift this to 39 and 40. I don't think it's as important for ESR 38, at least right now -- at this point I'm not anticipating uplifting any significant Windows 10 work to ESR, as our focus for the next few releases is going to on the mainline release channel. Getting Windows 10 great on ESR38 is a non-goal. That said, I'd be open to taking a few targeted, high-impact fixes on ESR later on, and this is probably a prerequisite for that. I think this patch would be safe to take on ESR -- I just want to set expectations (since this is the first bug where it's come up) that we will generally not be focusing any time on ESR for Windows 10.

This caused bug 1169981. Please do not land on ESR38, it really doesn't belong there anyway.

(In reply to Dão Gottwald [:dao] from comment #18) > This caused bug 1169981. Please do not land on ESR38, it really doesn't > belong there anyway. Shipping with bug 1169981 is better than having unreadable background tabs (#fff colored text, on #fff background). As I mentioned earlier, if we don't get this in ESR 38, the ESR branch will get unreadable background text for 6 months (after the Windows 10 launch), which is definitively critical.

The patch in bug 1061604 has been approved

https://hg.mozilla.org/releases/mozilla-esr38/rev/6abf6c91586a https://hg.mozilla.org/releases/mozilla-esr38/rev/49ed66febd2a

Tim, does this fix require manual verification? If so, could you please elaborate a bit on what manual QA can do here to help?

(In reply to Andrei Vaida, QA [:avaida] from comment #23) > Tim, does this fix require manual verification? If so, could you please > elaborate a bit on what manual QA can do here to help? Hi Andrei, can you test whether the testcase works properly on 41, 40, 39 and ESR 38 please ? (Win 10 should turn red on Windows 10)

(In reply to Tim Nguyen [:ntim] from comment #25) > Hi Andrei, can you test whether the testcase works properly on 41, 40, 39 > and ESR 38 please ? (Win 10 should turn red on Windows 10) Here are the test results for each Firefox version, using Windows 10 Pro Insider Preview (build 10130): * Nightly 41.0a1 (2015-06-14) - "Win10" turns red * Aurora 40.0a2 (2015-06-14) - "Win10" and "Default Theme" turn red * Beta 39.0b5 (20150611135623) - "Win10" and "Default Theme" turn red * ESR 38.0.1 (20150514102509) - "Win8" and "Default Theme" turn red Tim, what's your take on these?

(In reply to Andrei Vaida, QA [:avaida] from comment #26) > (In reply to Tim Nguyen [:ntim] from comment #25) > > Hi Andrei, can you test whether the testcase works properly on 41, 40, 39 > > and ESR 38 please ? (Win 10 should turn red on Windows 10) > > Here are the test results for each Firefox version, using Windows 10 Pro > Insider Preview (build 10130): > * Nightly 41.0a1 (2015-06-14) - "Win10" turns red > * Aurora 40.0a2 (2015-06-14) - "Win10" and "Default Theme" turn red > * Beta 39.0b5 (20150611135623) - "Win10" and "Default Theme" turn red > * ESR 38.0.1 (20150514102509) - "Win8" and "Default Theme" turn red This ESR build seems to be prior this fix (2015-06-08). Can you test on a more recent ESR, if any ? Default theme not turning red on nightly may be because you have a high contrast, or Aero basic/lite theme on.

(In reply to Tim Nguyen [:ntim] from comment #27) > This ESR build seems to be prior this fix (2015-06-08). Can you test on a > more recent ESR, if any ? Agh, you're right. Unfortunately, that's the latest ESR 38 build available, as far as I know. I'll take a look at this fix again when a new build is available. > Default theme not turning red on nightly may be because you have a high > contrast, or Aero basic/lite theme on. Yeah, that seems to be the case, thanks! Leaving the [qe-verify+] flag in place until this gets verified on ESR as well.

Verified fixed on ESR 38.0.1esrpre (tinderbox, 20150616140147), using Windows 10 x64 (build 10130).