Bug 50284

Subject: Related issue

Noticed one thing that probably is related.

In konqueror as file manager.
"Open Location..." www.lwn.net ENTER
Results in a query:
	Open 'http://lwn.net/' using 'Konqueror Web Browser'?
Accept with "Open"

This results in the same error message "There appears to be
a configuration error. ..."

Check for a file under .kde/share/mimelnk which defines an association for html 
with IIRC OpenOffice.org and remove it. 

Yes, that did work.      
I had two that looked like this (Note: had nothing to do with OpenOffice.org):     
::::::::::::::     
.kde[2]/share/mimelnk/text/html.desktop     
::::::::::::::     
[Desktop Entry]     
Comment=HTML-sida     
Hidden=false     
Icon=html     
MimeType=text/html     
Patterns=*.html;*.HTML;*.htm;*.HTM;*.asp     
Type=MimeType     
X-KDE-AutoEmbed=false     
  
     
But that also reset the setting - "show in  separate  viewer"  
If I reselects that the problem comes back!  
  
Why cant I select "show in separate viewer" as default when  
I can select  RMB -> Open With -> Konqueror web browser 
 
I still consider this as a bug! 

Well, you're telling Konqueror: please do not embed KHTML. 
Obviously this creates a problem, if you keep Konqueror associated with text/html. 
Revert Left Click Action to "show in embedded viewer", and Konqueror will be able to embed 
KHTML again. 
I see what you were trying to do ... but this setting is more than "should I use this window or 
should I create another window", it's actually "should Konqueror embed this viewer or not". 
To simply open another window with KHTML in it.... well I'd use a MMB click :) 
 
(Leaving bug open. Maybe this calls for re[de]fining the concept behind X-KDE-ShowAutoEmbed 
(the "Left Click Action" setting in the GUI). But not for KDE-3.1.) 
BTW this explains your Autostart-lwn.net problem. 

I found out one more thing today as I created a new and fresh user. 
 
It works somewhat, no new window is opened, until you associate another program with 
the mime type. Like "Open with...", Kate, remember 

Now I can reproduce this :-) 
 
Edit the "File Associations" text/html 
Add... 
   + Internet 
	Konqueror Web Browser (it execs "kfmclient openprofile webbrowsing") 
Move Up (to first position, or remove all other before adding this one) 
Apply 
 
Now try to click on any html: short cut... 
 
Summary: 
* removing all text/html applications 
* then readd the default KDE browser application 
Won't work. 
 
 
 

Today I noticed another bug which most likely has the same cause: 
If one views e.g. a PostScript file with the embedded viewer then afterwards it's no longer 
possible to view a HTML page with this Konqueror. Entering the URL by hand or selecting a 
bookmark results in the above mentioned error message "Konqueror can't handle text/html". 
Reverting the Left Click Action to "show in embedded viewer", as Coolo suggested fixed the 
problem (but I can't imagine a reason why I should have ever changed this setting to "show in 
extra viewer" for text/html). 
 
With a new user this problem does not occur. 
 

I can confirm this on KDE3.1 RC5 on Debian SID/Unstable. 
 
After viewing any other content than html in a window or a seperate tab 
konqueror returns the "Konquerer can't handle text/html" error message if 
you try to view a html page. It could be an image (jpg fx.), postscript, pdf or 
simple text even.  

There is a legitime reason to show text/html in external viewer - suppose you like to 
have mozilla as default text/html viewer! 
 
Retested with recent CVS. 
 
Configuring this, external viewer + mozilla on top, gives a number of surprices: 
* KTypeEditor will be "Updating System Configuration" twice to 100% for Apply. 
  And another 200% for clicking OK?! (related to problems below?) 
* Testing with a text/html file will give the error in this bug report. 
* Reopening the text/html config shows that mozilla is not on top (konqueror is) 
   even though mozilla.desktop has InitialPreference of 10 (konq has 9) 
   Is there special treatment of Konqueror? 
 
(BTW, I do not dare to right click to spell check - it crashed on me) 

Under the same conditions this also occurs when creating new tabs. 

I was told that this problem of associating text/html with any program was solved and indeed meanwhile (at least from KDE 3.1.3 on) it does not appear anymore. (I have Mozilla associated too. That never worked with the bug.)

So check your $KDEHOME and remove anything looking like handling HTML in there. (It will not be merge correctly.) Then run kbuildsycoca to be sure that the sycoca database is being rebuilt.

Have a nice day!

Folowing this advice from Stephan B :

------- Additional Comment #2 From Stephan Binner 2002-11-07 06:02 ------- 
> Check for a file under .kde/share/mimelnk which defines an association for html with IIRC OpenOffice.org and remove it. 

I renammed $HOME/.kde/share/mimelnk/text/html.desktop
THen it was recreated but with at the last line :
> X-KDE-AutoEmbed=true
in place of > X-KDE-AutoEmbed=false (as it was before)

And its workin' as far as now :)
 
 
 

Is it time to close this?

I think this problem arises because you have the need to open the file in different ways depending on the context. When you try to configure konqueror to behave a certain way when you work on local files, it unfortunately interferes with konquerors behaviour when you are browsing.

The only way I can see to fix this is to add multiple default actions that depend on the profile konqueror is operating with.

I have done some retesting.

Atleast two problems remains:
1) setting text/html to "Show in separate viewer"
    With Konquror as prefered application will cause the error.
    * Konqueror determines that it should start a separate viewer.
   [* New konqueror notices that html should be handled in an separate viewer.
    Repeat and you have: http://bugs.kde.org/show_bug.cgi?id=22457]
    Old Konqueror checks and determines that new konqueror will not be able
    to handle html and reports error - i.e this bug.
    Since if konqueror is started form konsole it works!
	konqueror index.html -or-
	kfmclient openURL index.html text/html
    Note: going up one level and then click on index.html fails!

[Same thing can happen with other mime types
 Set image/jpeg to "Show in separate viewer" and konqueror as prefered application. Using konqueror to open a jpeg from konsole, this works. But
from konqueror as file manager it fails...]

Bug is still valid!

2) Application preference order not persistently stored - bug 81374

http://lists.kde.org/?l=kde-cvs&m=108599718224737&w=2 may have addressed this

Testcase in #6 works fine in CVS HEAD.
Testcase in #7 works fine in CVS HEAD.

#9: the dual progressbar is probably due to running once to create the application's .desktop file and running another time to associate it with the given mimetype. After changing the order of things in the mimetype editor dialog, the order is saved into the profilerc config file - the InitialPreference is called initial because it only applies before editing preferences.
There's new code in head for per-mimetype preferences though (in the mimetypes line itself), not sure how that relates to profilerc nowadays... (Waldo added it)

Associating mozilla as the preferred text/html viewer works ok. A few funny side effects exist though, like pressing F5 in konqueror after using "preview in KHTML" for an html file. Upon reloading we recheck the mimetype and use the preferred way of showing it - so it fires up mozilla.... Small issue I guess.

Testcase in #14 1) works fine in CVS HEAD, 2) isn't reproducible (the order is kept).

Hmm, any use of KHTML when associating text/html to Mozilla is almost impossible... I mentionned reload, but even submitting a form from khtml works strangely, since it wants to open mozilla with the result of the form.
OTOH this is happening to me just now because I switched the preferrence to mozilla after starting in KHTML, but I guess that the whole idea behind this bug is that some people don't want to use khtml at all, so they wouldn't end up in this weird situation... Anyway the filemanagement-related bug is fixed, closing. Ah, will backport.

No I would say that the idea is:

1. A wish to use separate viewer for text/html and other mime types.
   Test case:
	Let konqueror remain at top of viewer list.
	Select "Show file in Separate Viewer."
	=> opens in preview
   Result:
	Does not work in cvs.


2. A wish to use other browser than konqueror as default separate
   viewer for text/html
   Test case:
	same as 1. but with mozilla on top of list
   Result:
	Works with cvs!

3. A wish to be able to use konqueror when explicitly requested.
   Test case:
	same as 2.
	Open with: konqueror
   Result:
	I think this works with cvs.

Note: Since this can be configured => bug not wish request.
Note2: Used CVS from tonight, was fix checked in lately? (I leave it as fixed for now)

I just had this problem bite me after upgrading from 3.2.1 to 3.2.3. As a workaround, I simply removed the .kde/share/mimelnk/text/html.desktop, which contained the following two lines only:

           [Desktop Entry]
           X-KDE-AutoEmbed=false

Bizarrely, Konqueror was loading the first page of any bookmark fine. But following a link on the first page caused the 'Konqueror can't process text/html' message. 3.2.1 worked fine. An ugly bug.

CVS commit by faure: 

Fixed clicking on links to anchors when setting "open text/html in external viewer".
(nothing would happen).
CCMAIL: 50284@bugs.kde.org


  M +2 -0      konq_mainwindow.cc   1.1337


--- kdebase/konqueror/konq_mainwindow.cc  #1.1336:1.1337
@@ -934,4 +934,5 @@ void KonqMainWindow::openURL( KonqView *
   req.args = args;
 
+  // Clicking on a link that points to the page itself (e.g. anchor)
   if ( !args.doPost() && !args.reload &&
           childView && urlcmp( url.url(), childView->url().url(), true, true ) )
@@ -942,4 +943,5 @@ void KonqMainWindow::openURL( KonqView *
 
     childView->stop();
+    req.forceAutoEmbed = true;
     openView( serviceType, url, childView, req );
     return;