Bug 242417 - webkit kpart doesn't respect text/plain file associations...
Summary: webkit kpart doesn't respect text/plain file associations...
Status: RESOLVED UPSTREAM
Alias: None
Product: kwebkitpart
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: webkit-devel
URL:
Keywords:
: 320252 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-06-21 22:00 UTC by Adrian von Bidder
Modified: 2013-05-27 17:48 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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. ***