Closed
Bug 1193956
Opened 9 years ago
Closed 3 years ago
Setting gfx.xrender.enabled to false makes a profile unusable
Categories
(Core :: Graphics, defect, P3)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: hotsopdotcom, Unassigned)
Details
(Whiteboard: [gfx-noted])
Attachments
(1 file)
18.21 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150807095004
Steps to reproduce:
Linux Mint 17 Qiana's Update Manager installed the latest Mozilla security update. Afterwards, almost all of my several profiles wouldn't open.
Actual results:
Firefox would start, show the profile selector, but after I selected a profile it would only show a completely empty window (or at most a window with a title bar). No menus, address bar, etc. When I tried to launch in safe mode, the same thing would happen except this time the safe mode window was empty: no text or buttons.
However, an existing stock profile and a new profile would open as expected.
In a new profile I created, I set gfx.xrender.enabled to false, and I subsequently wasn't able to open that profile. I found that when I deleted the line with gfx.xrender.enabled from prefs.js in one of the profiles that didn't open, I was then able to open that profile.
gfx.xrender.enabled set to false is needed to keep the address bar from showing a black bar. So, it looks like I can now open the existing profiles, the trade-off is the address bar isn't too functional.
Updated•9 years ago
|
Component: Untriaged → Graphics
Product: Firefox → Core
Updated•9 years ago
|
Whiteboard: [gfx-noted]
Comment 1•9 years ago
|
||
I can't seem to reproduce with Firefox 40 on Ubuntu 14.04, nor with nightly on Debian Jessie.
Chances are this is an issue with X11 SHM and OMTC. I'm not sure why SHM would be failing (should be supported by all modern X servers), but one option to consider may be implementing a readback into the window if SHM fails.
Reporter | ||
Comment 2•9 years ago
|
||
The update that caused the problem was applied shortly after the previous update (39.9?) So, whatever it is that's causing this happened just before 40.0. This is an older computer using an Intel 82845G/GL chip so maybe the problem isn't there on newer computers.
No Interface for me with Fx 40.0 on Debian 8 KDE (NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1)).
No problem with Fx 39.0.3 & Fx 41.0a2 with this preference.
Setting gfx.xrender = true solved the problem of any keyboardinput not being updated grafically. The rendering update took very long and could only be forced by moving the mouse.
Updated•7 years ago
|
Priority: -- → P3
Updated•3 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•