Besides that, Abiword is configured to open xhtml+xml. That should also be changed to a valid browser application, e.g. Midori.

That's really strange. Let me look.

Ok, the problem is gtk-find icon seems to be missing from gnome icon themes. Only theme that seems have the icon theme is Rodent - which brings back the nice magnifying glass icon.

Darn it! Wrong bug report! Sorry!

This may be a geany bug... 

it has: 

MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff;

in it's desktop file. 

If you remove geany, what do you get for the release notes?

(In reply to Kevin Fenzi from comment #5)
> This may be a geany bug... 
…
> If you remove geany, what do you get for the release notes?

Okay, that was the right hint. If there's both no geany *and* no abiword installed (by yum remove geany abiword), the release notes get open in midori.

(In reply to Raphael Groner from comment #6)
> 
> Okay, that was the right hint. If there's both no geany *and* no abiword
> installed (by yum remove geany abiword), the release notes get open in
> midori.

Shall I close this bug now that it has been ascertained that it's not xfconf?

How do you want to tell the end-user to remove any by default installed editor (geany, abiword, whatever…) from the running live spin to be able to read the release notes properly?

There should be a patch for xdg-open to enforce the default webbrowser for an html file.

$ grep Exec /usr/share/applications/fedora-release-notes.desktop 
Exec=xdg-open file:///usr/share/doc/fedora-release-notes/index.html

Reassigning to geany in the hope to get the "text/html" entry removed there. Same must be done later for abiword.

No. It's ridiculous to assume that no other application will modify the mime configuration at any time. So this bug goes against fedora-release-notes package itself: Enforce that a web browser is installed that can render the notes properly and that browser is used therefore.

So, does this only happen in the Xfce spin? If so we may be able to set things in the kickstart so it works correctly. 

However, if the problem is more wide than that, perhaps we should look at a fix in xdg-open instead?

If xfce wan't to ship custom default applications/mimetypes (that vary from distro defaults), one way to do that is to follow:

http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html#file

and ship a customized

/usr/share/applications/xfce-mimeapps.list

I do not like the idea to use xdg-open. In case of Xfce, it is better to use:

exo-open --launch WebBrowser file://%{_docdir}/%{name}/index.html

This will ensure the release notes do always open in the default web browser what is the commonly expected behaviour when the menu entry gets clicked, without touching mime configuration at all. If the user may wish, there could be an editor (or whatever other application) as default to open any html file.

From the package's spec file I can see that for GNOME, there's already a separate desktop file to show with epiphany instead.

http://docs.xfce.org/xfce/exo/preferred-applications

I can do a desktop file just for XFCE.... but are you really that attached to the idea of an editor being the default handler for HTML files?  I think this is not what users would generally expect, regardless of whether the file opening is initiated from a menu launcher or double clicking a file or whatever.

I still think some variant of custom mimetype defaults (comment #11) possibly combined with exo preferred apps (comment #13) is the way to go here.

In short, it's a xfce configuration issue, definitely not a release notes bug (as is assigned now).

(In reply to Rex Dieter from comment #15)
> I still think some variant of custom mimetype defaults (comment #11)
> possibly combined with exo preferred apps (comment #13) is the way to go
> here.

I agree. I've just not had time to work on the defaults, and the last f22 nightly I tried things worked out of the box. 
> 
> In short, it's a xfce configuration issue, definitely not a release notes
> bug (as is assigned now).

I agree.

Reassigning back to xfce specific then, exo seems to be a good base component.

An installed Xfce 4.12 of Fedora 22 Beta-3 with current updates still opens the Release Notes in Abiword.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Reverting to rawhide. This bug is not fixed yet.

Still reproducible with latest Fedora-Live-Xfce-x86_64-23-20150728.iso

Yes, I know. I have simply not yet had time to deal with this. 

It's on my todo list. will try and get to it soon.

This may be mitigated a bit by

shared-mime-info-1.4-6

http://pkgs.fedoraproject.org/cgit/shared-mime-info.git/commit/?id=458290b30b7b97a024dcd564ed0ac7c3fc3f2a97

Sure, but we still want/need a xfce specific one... :)

Could it be solved with bug #1243049 ?

Applied the update of shared-mime-info from bug #1243049 but it did not change anything for the wrong mime type configuration of html (standard for text/html is Geany as mime type editor tells me, Abiword for application/xhtml+xml). Tested both in f22 and f23 with all latest updates installed.

shared-mime-info-1.4-6.fc23.x86_64
shared-mime-info-1.4-6.fc22.x86_64

Odd,

$ grep html /usr/share/applications/mimeapps.list 
text/html=firefox.desktop
application/xhtml+xml=firefox.desktop

It should default to firefox now.

We don't ship Firefox in the Xfce Live Spin (any more). But there's Midori.

ok, that would indeed be the problem here (and why a custom xfce-mimeapps.list would be required)

So, thinking about it, I think we should ship this in xfce4-session. It's the place that sets the session that this would use, so you need it to use the mimeapps list anyhow. 

Toward that end, I have pushed out to rawhide: 

https://koji.fedoraproject.org/koji/taskinfo?taskID=10648917

would like to let it get some testing there (we should be able to check rawhide live media after today). 

If that looks good we can push to f23.

Fedora-Live-Xfce-x86_64-rawhide-20150811.iso does NOT show this issue, so it's fixed. Thanks!

This seems to be a failure of Testcase desktop menus.
https://fedoraproject.org/wiki/QA:Testcase_desktop_menus

I'm confused... this should be fixed? or why is it a menu failure?

From the test expectation:
" Each application in the default system menu layout should launch without crashing and withstand basic usage. Bugs should be filed in any case where this does not happen "

So choosing release notes from the menu causes a crash? 

Or works? In comment 31 you said it worked?

It's now fine in f24 image. But we have to ensure it's also working for -final- f23 spin image.

Discussed at 2015-08-20 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-08-20/f23-blocker-review.2015-08-20-16.05.log.txt . Accepted as a blocker per cited criterion: Xfce is now a release-blocking desktop for ARM, and we expect this bug is present in the ARM image.

xfce4-session-4.12.1-5.fc23 has been submitted as an update to Fedora 23. https://bugzilla.redhat.com/show_bug.cgi?id=1199252

xfce4-session-4.12.1-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update xfce4-session'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-13841

Thanks. This works now in updated Fedora 23 nightly.

xfce4-session-4.12.1-5.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.