Bug 242417

Summary:	webkit kpart doesn't respect text/plain file associations...
Product:	[Frameworks and Libraries] kwebkitpart	Reporter:	Adrian von Bidder <avbidder+kde>
Component:	general	Assignee:	webkit-devel
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	adawit, arojas, miklcct, rasasi78
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Debian unstable
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Adrian von Bidder 2010-06-21 22:00:19 UTC

Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

Heyho!

(I'm forwarding this from Debian #586514)
+++
When you first open an HTML page with webkit kpart in Konqueror and click a
link to a text/plain document, the webkit part itself shows the text/plain
document but not the expected katepart as stated in file association settings.
This prevents me from editing the remote text document unless I manually switch
to katepart.
+++

And I can confirm this: although I have configured text/* to show in "separate viewer" and text/plain to "use settings from group text", the kpart will open a text/plain document (example: the "mbox" link in the debian bug report on http://bugs.debian.org/586514) inline.



Reproducible: Always

Comment 1 Dawit Alemayehu 2010-06-22 08:08:33 UTC

I have changed the title of the bug report to reflect the actual problem reported. KWebKitPart does not honor file association for text/plain mime-type. The reason for that is simply because QtWebKit automatically renders such resource and does not provide/expose the means to limit it to handling only certain mime-types. As such this is an upstream issue. 

However, because there is a possible workaround that should be explored to see if it can be used to address this issue, amongst others, this ticket will be left open until the investigation of the possible workaround is finished...

Comment 2 Adrian von Bidder 2010-06-22 10:33:28 UTC

Ok, thanks.

Comment 3 Dawit Alemayehu 2010-12-18 20:03:37 UTC

Unfortunately we cannot work-around this problem here ; so a ticket has been opened upstream... See https://bugs.webkit.org/show_bug.cgi?id=51292

Comment 4 Michael Tsang 2011-04-08 12:30:58 UTC

I don't think that this bug is "resolved". I think that it should be tagged "upstream" instead of "resolved" so that we can return here when upstream solves the issue.

Comment 5 Michael Tsang 2011-04-08 12:33:58 UTC

(In reply to comment #4)
> I don't think that this bug is "resolved". I think that it should be tagged
> "upstream" instead of "resolved" so that we can return here when upstream
> solves the issue.

Sorry, I have mistaken the word "resolved". This bug hasn't been closed yet.

Comment 6 Raúl 2012-06-26 16:55:01 UTC

Hello:
I don't have an account on webkit bugzilla, therefore I'm commenting here, which by the way should be good to have. I still appreciate if anyone with an account there could transport this status update.
I think this is still valid. Tested with KDE 4.8.4, Qt 4.8.2, QtWebKit 2.2.1 and current kwebkitpart master (1.3 pre).
In order to reproduce this follow these steps:
· Go to http://mozilla.durys.net/textplain/
· Make sure you are using the webkit kpart (konqueror view menu->viewmode->webkit)
· Click on "Changes history" link, close to the page bottom.
· See as text is rendered by webkit.

  Regards,

Comment 7 Dawit Alemayehu 2013-05-27 17:48:33 UTC

*** Bug 320252 has been marked as a duplicate of this bug. ***