| Projekt: | Trisquel |
| Komponente: | Gnome |
| Kategorie: | Fehlerbericht |
| Priorität: | minor |
| Zugewiesen: | nicht zugewiesen |
| Status: | closed |
System Information:
Trisquel 5.5
Abrowser 11.0
Steps to reproduce:
1) Find an image online with abrowser
2) Right-click on image and select "Set as Desktop Background..."
3) Desktop background will not change but a file will appear in the users home directory called "Abrowser_wallpaper.png"
4) The user then can use that file by right-clicking on the desktop and selecting "Change Desktop Background" and changing the wallpaper in the GNOME appearances menu.
Expected Behavior:
1) After right-clicking on the image and selecting "Set as Desktop Background..." the background should change. The user should not have to go through the extra step using the GNOME appearances menu.
I'm having this problem as well.
I can recreate the bug. So far I have determined that the bug still happens in safe mode so it isn't an extension or plugin that is the problem. Further it still fails in a Gnome Shell session so it isn't some fallback session weirdness.
The code that handles this function is in mozilla/browser/components/shell/src/nsGNOMEShellService.cpp starting at line 408 in method
nsGNOMEShellService::SetDesktopBackground(nsIDOMElement* aElement,
PRInt32 aPosition)
Testing with the command line utilities gconf-editor and gsettings I can see that the desktop background settings are getting through to gconf but not gsettings. Further the gsettings command line equivalents of the code between lines 473 aand 481 do actually work. This must mean that the if(gsettings) on line 465 is testing false.
gsettings is assigned in method nsGNOMEShellService::Init() in the same source file with a do_GetService. From the names of the methods I think this is routed eventually to the method
nsComponentManagerImpl::GetServiceByContractID(const char* aContractID,
const nsIID& aIID,
void* *result)
at line 1378 in mozilla/xpcom/components/nsComponentManager.cpp .
At this point my insomnia has worn off and it's time for bed. Posting this note and leaving the bug unassigned as there may be people who will get somewhere very quickly with this info.
This works for me now. Could someone else who was able to recreate the bug try it with abrowser 13. If it works for them please mark as fixed. Thanks.
Just to confirm that I also had the issue previously, at least up to Abrowser 12, and that it is working properly now with Abrowser 13.
I cannot mark it as fixed, though.
Automatically closed -- issue fixed for 2 weeks with no activity.