Closed Bug 1269092 Opened 8 years ago Closed 10 months ago

Compatibility bug with Windows 7 Aero

Categories

(Core :: Widget: Win32, defect, P4)

45 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: quality+bugzilla, Unassigned)

Details

(Whiteboard: tpi:+)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160421124000

Steps to reproduce:

1. Install Windows 7 Premium SP1 64-bit and all security patches.
2. Install 32-bit version of Firefox 45.0, 45.0.1, 45.0.2, or 46.0.
3. Install f.lux v3.10
4. Set f.lux transition speed to slow (60m).
5. Use Firefox and its developer tools.


Actual results:

On rare occasions, Windows will display the following error and disable Aero.  Closing Firefox restores Aero.  No other applications cause this error.

Multiple data points suggest (but do not conclusively confirm) that this happens when Firefox is running while f.lux is performing its 60 minute transition.  It's quite possible that f.lux is a red herring, but given that this is a sporadic issue, I feel it is better to over-report possibly relevant data instead of under-report.

Here is the error, verbatim:

Windows

The color scheme has been changed

The following program has performed an action that requires
Windows to temporarily change the color scheme to Windows
7 Basic.

Program: Firefox
Publisher: Mozilla Corporation
Process identifier (PID): xxxx

Windows will automatically change the color scheme back to
Windows Aero when this program or other programs
performing similar actions are no longer running.


Expected results:

Firefox should always be 100% compatible with Windows Aero.

It should never cause a Windows component to fail.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Component: Untriaged → Widget: Win32
Product: Firefox → Core
Update: Bug still present in Firefox 47.0.1
Are you able to reproduce the issue with old versions of Firefox like 40 or 35?
(if you want to test, releases are available here: http://ftp.mozilla.org/pub/firefox/releases/ )
The earliest version of Firefox I tested this on was 45.0.  I also tested it with 45.0.1, 45.0.2, 46.0.0, and 47.0.1.  The bug was present in all those versions.

I wish I had time to test it with older versions, but unfortunately I have too many other commitments at this time.
Priority: -- → P4
Whiteboard: tpi:+
Quick update: Issue still present with Firefox 53.0.2 (multiprocess enabled).
Another update: Issue still present with Firefox 53.0.3 (multiprocess enabled)
Severity: normal → S3
Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago
Resolution: --- → INVALID

Reopening. :gregp, please add a reason for closure when closing "RESOLVED INVALID".

(Note that we're not closing Win7 bugs just because they're Win7; I wouldn't expect that to happen, even for mostly-cosmetic bugs, until Win7 is no longer supported even in ESR.)

Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

I closed this bug because the user's account is disabled and I wasn't able to reproduce on my Win7 machine.

I assume that this bug depends on a combination of a specific incarnation of hardware accelerated graphics in Firefox, f.lux version, and GPU driver version.

Since we can't communicate with the reporter I just closed it, sorry for not explaining 😀

Sounds good. Reclosing as RESOLVED WORKSFORYOU. 😉

Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago10 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.