Bug 313819

Summary:	Rekonq displays source HTML instead of rendered HTML if file extension is missing
Product:	[Unmaintained] rekonq	Reporter:	Peter Lewis <pete>
Component:	general	Assignee:	Andrea Diamantini <adjam7>
Status:	RESOLVED UNMAINTAINED
Severity:	normal
Priority:	NOR
Version First Reported In:	2.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Peter Lewis 2013-01-24 10:33:47 UTC

I use rekonq to display HTML parts of emails, and launch it through mutt to do that. As a result many of the files that rekonq is being asked to load do not have a file extension (i.e. they are named something like /tmp/muttu1234, not something.html.) When rekonq loads these files, it usually just displays the HTML source, instead of the rendered HTML. This is true whether rekonq is launched from mutt or elsewhere.

Reproducible: Always

Steps to Reproduce:
1. Create a file called "email" with one line only: Here is <a href=http://www.google.com>the link to google</a> I told you about.
2. Copy that file exactly to email.html: cp email email.html
3. Open rekonq on each file separately:
a) rekonq email
b) rekonq email.html

Actual Results:
The file "email" is displayed with the raw source HTML. The file email.html is displayed with rendered HTML.

Expected Results:
Both files are the same and should be rendered in the same way. Rekonq should probably use libmagic or similar to determine the file type. For example, on those two files, we get:

% file email
email: HTML document, ASCII text
% file email.html
email.html: HTML document, ASCII text

i.e. the system knows that they are HTML documents.

An exception to the above file extension case is when the file actually contains <html> and </html> tags. It seems that rekonq is doing some ad-hoc checking of file type (looking for an extension and/or <html> tags) and rendering accordingly. It would be more robust if libmagic were to be used.

Thanks!

Comment 1 Peter Lewis 2013-05-23 10:31:50 UTC

Hi, any thoughts about this bug? It's still annoying me in 2.3.0. Is there any way I can help?

Comment 2 Andrea Diamantini 2013-05-23 16:46:32 UTC

I'm sorry to say this is not  in any way a rekonq bug, but a qtwebkit missing feature being it NOT able to correctly interpret local files without extensions.
I'm trying some tricks to, but this actually seems too much hackish.

Comment 3 Peter Lewis 2013-05-24 12:39:41 UTC

Thanks for looking into it Andrea. So, in your opinion should this be raised as a bug against qtwebkit?

Comment 4 Andrea Diamantini 2013-05-24 14:18:32 UTC

yes


2013/5/24 Peter Lewis <pete@muddygoat.org>

> https://bugs.kde.org/show_bug.cgi?id=313819
>
> --- Comment #3 from Peter Lewis <pete@muddygoat.org> ---
> Thanks for looking into it Andrea. So, in your opinion should this be
> raised as
> a bug against qtwebkit?
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
>

Comment 5 Peter Lewis 2013-05-24 16:00:27 UTC

Done: https://bugreports.qt-project.org/browse/QTBUG-31350

Comment 6 Peter Lewis 2013-05-24 16:53:40 UTC

I guess from reading the response from the Qt dev, they think that this should be done in rekonq :-/

Comment 7 Andrea Diamantini 2013-05-24 17:16:46 UTC

I'm pretty convinced this has more sense being done in qtwebkit. But given they won't, I can try implementing it somewhere.

Comment 8 Nate Graham 2018-05-11 16:29:37 UTC

Development on Rekonq ceased four years ago, and it has been unmaintained since then. KDE recommends using Falkon instead.