Version: 1.0.0 (using Devel) OS: Linux Installed from: Compiled sources I am using kopete 1.0.0 in KDE 4.4 SC RC 2 I have firefox as my default browser in systesettings, but whenever I get a pop-up notification for MSN mail it opens in konqueror. All other links open in firefox.
This is not really a bug to make Kopete be able to open links in Firefox you need to change the default program that open html file. By default in KDE it is set to Konqueror you need to go to System Settings > Advanced > File Association look for html and put Firefox at the top of the list. Hope that will help.
The trouble is that users expect that when they change their default web browser that the HTML file types will go with it. To a large extent it makes sense. HTML files are typically viewed with a web browser even if the HTML file doesn't come from the web (eg the file is from local storage). This technically isn't a Kopete bug but a usability bug in KDE's System Settings dialogs. I propose that System Settings/Default Applications/Web Browser should ask the user if it should change a few file associations too. Alternatively, it could suggest to the user that he or she may want to review settings in System Settings/File Associations.
Currently Kopete creates a temporary file and uses the default association for .HTML files to open it. The temporary file uses some kind of "meta http-equiv=Refresh" magic to avoid having the user reenter their MSN log in credentials. This is a fairly solid case for changing file associations with the "Default Browser" setting. (IMHO)
In my opinion this bug can be easily fixed by using KToolInvocation::invokeBrowser() instead of KRun() for opening the html file. That way there is no file association change needed to get the inbox to open in your preferred browser. I can supply a patch file if needed, I don't have the current source right now.
Okay, thanks for the idea. But will it be right solution (as for this bug - of course, yep)? I mean, shouldn't we suggest the user to change his text/html viewer in mime-type when he selects the default browser?
Well Igor, in my opinion it is. The only thing the temporary html file does is set up the username and password and redirect to the online inbox. Many people won't even know what happens behind the scenes and would expect the inbox to open in their preferred browser, not in their preferred HTML file application. I can think of situations where people would assign a non-browser application for opening local HTML files, for instance a text-editor. Asking these people to change their file associations without them knowing why would be annoying I believe. Explaining why they would have to change their file association would result in a large message box no-one reads. Another issue is that changing the file associations in KDE isn't exactly a user-friendly process and could easily result in misconfigured systems for people who don't know what they are doing. Regards, Pieter.
Okay, Pieter, I'm totally agreed with you. I was talking about idea from comment #2, but looks like it is just an another bug. Someone should fill an another wish/bugreport for it (for browser component chooser) and we can discuss and/or fix it.
Ah I see this bug is fixed in the latest svn. I wanted to create a patch but you fixed it already! :) As for the idea of asking the user to change his file associations: what part of KDE would that fall under, for those who wish to open a feature request for that? Thanks a lot! Pieter.
No problems :) It should be for product 'systemsettings' and component 'kcm_componentchooser' (where user selects his default browser)
SVN commit 1176400 by poboiko: Backport commit 1176365 Open hotmail inbox using default web browser (not a default html viewer) CCBUG: 225043 M +1 -3 wlmaccount.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1176400
If there's someone out there with rights, Bug 249710 seems to be a duplicate of this one.
In regards to opening up a new bug, how about Bug 217017 ?
*** Bug 249710 has been marked as a duplicate of this bug. ***
*** Bug 253242 has been marked as a duplicate of this bug. ***