Closed
Bug 1269092
Opened 8 years ago
Closed 10 months ago
Compatibility bug with Windows 7 Aero
Categories
(Core :: Widget: Win32, defect, P4)
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.
Reporter | ||
Updated•8 years ago
|
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Reporter | ||
Comment 1•8 years ago
|
||
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/ )
Reporter | ||
Comment 4•8 years ago
|
||
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.
Updated•8 years ago
|
Priority: -- → P4
Whiteboard: tpi:+
Reporter | ||
Comment 5•7 years ago
|
||
Quick update: Issue still present with Firefox 53.0.2 (multiprocess enabled).
Reporter | ||
Comment 6•7 years ago
|
||
Another update: Issue still present with Firefox 53.0.3 (multiprocess enabled)
Updated•2 years ago
|
Severity: normal → S3
Updated•10 months ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago
Resolution: --- → INVALID
Comment 7•10 months ago
|
||
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 → ---
Comment 8•10 months ago
|
||
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 😀
Comment 9•10 months ago
|
||
Sounds good. Reclosing as RESOLVED WORKSFORYOU. 😉
Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago → 10 months ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•