Bug 857257 - RC3-Alpha Xfce spin: firefox doesn't open first time.
RC3-Alpha Xfce spin: firefox doesn't open first time.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Horak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-13 19:35 EDT by Sergio
Modified: 2014-02-05 17:47 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 17:47:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sergio 2012-09-13 19:35:28 EDT
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:
Comment 1 Bill Nottingham 2012-09-14 12:22:40 EDT
Moving to exo - if you can reproduce this on non-XFCE live images, please move this to firefox itself.
Comment 2 Kevin Fenzi 2012-09-14 12:41:38 EDT
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?
Comment 3 Sergio 2012-09-14 12:57:45 EDT
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.
Comment 4 Kevin Fenzi 2012-09-21 15:20:25 EDT
Could you perhaps retry this with the final alpha and see if it still persists?
Comment 5 Sergio 2012-09-21 16:22:10 EDT
Ok, will do.
I thought that final Alpha was the same as RC3.
Comment 6 Kevin Fenzi 2012-09-21 16:25:13 EDT
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.
Comment 7 Sergio 2012-09-21 16:27:02 EDT
I can try with this one:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4511994
Comment 8 Sergio 2012-09-21 20:00:10 EDT
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).
Comment 9 Kevin Fenzi 2012-09-22 16:15:37 EDT
ok, could be some stange firefox issue... lets move it over there for them to comment on.
Comment 10 Sergio 2012-09-23 09:30:43 EDT
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.
Comment 11 Sergio 2012-09-25 08:08:28 EDT
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.
Comment 12 Sergio 2012-09-25 08:10:38 EDT
Scrap that last comment. Of course it's being copied (just look at my precious comment).
Sorry.
Comment 13 Jan Horak 2012-10-03 11:16:45 EDT
Hm, can I get this live cd/dvd image somewhere? It might be related to profile creation (if system is on read only environment).
Comment 14 Kevin Fenzi 2012-10-03 11:22:54 EDT
The xfce live from: 
http://fedoraproject.org/get-prerelease
Comment 15 Sergio 2012-10-03 11:25:10 EDT
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.
Comment 16 Sergio 2012-10-03 16:40:44 EDT
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.
Comment 17 Fedora End Of Life 2013-12-21 10:05:58 EST
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.
Comment 18 Fedora End Of Life 2014-02-05 17:47:56 EST
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.

Note You need to log in before you can comment on or make changes to this bug.