Description of problem: clicking on the 'Web Browser' launcher on the bottom panel of the Xfce spin desktop (which executes 'exo-open --launch WebBrowser %u') first time the cd spins, it calls firefox but soon the process silently dies (no errors in ~/.xsession-errors except 'Error: No running window found' but this it outputs even when it works). Second time Firefox opens normally. Version-Release number of selected component (if applicable): How reproducible: always, since RC2-Alpha this behaviour was already present. Steps to Reproduce: see description. 1. 2. 3. Actual results: see description. Expected results: should open browser on first click. Additional info:
Moving to exo - if you can reproduce this on non-XFCE live images, please move this to firefox itself.
I don't see this on live images here. ;( Does it work every time after the initial issue? If you reboot does it happen every time on a fresh boot? if you reboot and manually run the command from a terminal does it fail the first time?
Then maybe it's just some glitch that happens with my system. It happened both in rc2 and rc3. After the first failed try it works normally. In rc3 I tested more, opening the task manager to have a look and there I found that exo succeeded to call firefox [firefox -remote openUrl(about:blank;new window)] but then after a while the cd stop spinning and it just fails. Next try it sticks. I can't test the installed system currently (my HD is 30GB, don't laugh/cry). But I did notice some inconsistency that made me think it's just my system struggling to run the live-cd: once, after testing, I logged out back to lightdm, logged back into the desktop and the failing behaviour repeated. I did the same test in another boot but this time on the second login it worked the first time I clicked the launcher (it had failed, as always, on the first login). So, all-in-all, I don't think it's an exo issue. it could be something with firefox or, to put it better, with the environment as firefox is very susceptible. But *if* it was anything to do with firefox we would need first to see how version 15 works as version 14 is already old and may cause trouble (it did here in my installed F17 before I updated it). I think we can kind of ignore this at this stage, maybe.
Could you perhaps retry this with the final alpha and see if it still persists?
Ok, will do. I thought that final Alpha was the same as RC3.
Ah, indeed it was. So, not sure here... perhaps keep an eye out on this and see if it hits anyone else, or goes away as we get nearer release.
I can try with this one: http://koji.fedoraproject.org/koji/taskinfo?taskID=4511994
Still there. At first login there are only 'extensions' and 'plugins' empty folders under ~/.mozilla Then I run 'exo-open --launch WebBrowser %u' this starts firefox but it doesn't even open the GUI and it silently terminates. After this first 'run' we have: $ tree .mozilla/ .mozilla/ ├── extensions │ └── {ec8030f7-c20a-464f-9b0e-13a3a9e97384} ├── firefox │ └── Crash\ Reports │ └── InstallTime20120911180315 └── plugins 5 directories, 1 file Then next time I run 'exo-open --launch WebBrowser %u' firefox opens normally and populates ~/.mozilla This is the same behaviour as before. Now there was a misbehaviour that I didn't encounter in the other isos: firefox failed to open the start page and instead tried to open 'http://www.%u.com/' (and failed, of course).
ok, could be some stange firefox issue... lets move it over there for them to comment on.
This thing of it not opening the start page isn't a bug. I found that it does the same thing in my installed system but it's because I launched it from the command-line (and in a real situation one wouldn't use %u for the URL). Clicking on the menu icon (launcher) works properly.
I'm testing the same 21-Sep nightly for other things and I noticed about Firefox: - first time I launched it now was from the xfce4-screenshooter upload window and it opened properly in the selected link (it opened just that page; it showed the 'know your rights' tab but didn't open the fedoraproject.org in another tab). - I noticed that the only content in /etc/skel besides the .bash* files is .mozilla, which just has empty 'extensions' and 'plugins' directories. Maybe this is affecting this issue? Maybe there should just be no .mozilla in skel? Or yet the issue looks like that, probably due to my slow hardware coupled with inherently slow live-cd, plus whatnot (like when liveuser is being generated, IDK if it's done at boot time or when building the iso), simply the .mozilla folder isn't copied from /etc/skel to ~ automatically as it should. I noticed other inconsistencies with other apps from when I first login and when I logout and login a second time. That's why I suspect that if it isn't some bug on the live system it maybe just my hardware struggling to run it.
Scrap that last comment. Of course it's being copied (just look at my precious comment). Sorry.
Hm, can I get this live cd/dvd image somewhere? It might be related to profile creation (if system is on read only environment).
The xfce live from: http://fedoraproject.org/get-prerelease
You can get the Beta TC1 image at http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC1/Live/ * or where Kevin posted. But it might be just an issue with my weak system, because last time I was testing it I had some apps open, had made some things like installing software etc. so the memory was quite stressed (I have 1GB RAM and the encrypted swap I couldn't figure how to mount so that really was an issue) and I left the PC for a while and when I came back Firefox had simply disappeared (closed by itself). I attributed it to some difficulty in dealing with the lack of memory. Opening it again it worked ok.
It worked fine now (beta tc1). After Xfce loaded I didn't do anything, just logged out and back in. Then I clicked the 'Web Browser' launcher and Firefox opened alright. I did this logout/login thing because for instance the network notification doesn't show for me in the first login but after logging out, with session saved, then it shows up next login. Auto-mount too varies depending if file manager had been opened or not etc.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.