Date: Mon, 30 Apr 2012 21:23:05 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Evan Martin <evan@chromium.org> Cc: chromium@freebsd.org, hackers@freebsd.org Subject: Re: how to display C sources in Chromium (file:/// only) Message-ID: <20120430192305.GA72227@onelab2.iet.unipi.it> In-Reply-To: <CAFzwtj3TDpxHs93dc0PGM-JcxFPNL%2B2kUtsfcZDi-AhqZBS2hQ@mail.gmail.com> References: <20120428144745.GA40844@onelab2.iet.unipi.it> <CAFzwtj3TDpxHs93dc0PGM-JcxFPNL%2B2kUtsfcZDi-AhqZBS2hQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 30, 2012 at 08:47:21AM -0700, Evan Martin wrote:
> On Sat, Apr 28, 2012 at 7:47 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:
> > (hoping this is of interest for hackers- too)
> >
> > One of the most annoying features of chromium is that it downloads
> > instead of displaying various types of files (.c, .h and so on).
>
> This has long annoyed me too!
>
> > it seems that a partial fix can be achieved by arring the list of
> > types we want to display to the array
> >
> > ? ?static const char* const supported_non_image_types[] = {
> > ? ? ? ?...
> > + ? ? ? "text/x-csrc",
> > + ? ? ? "text/x-chdr",
> > ? ? ? ?...
> > ? ?}
>
> There's a comment at the end of the block:
> // Note: ADDING a new type here will probably render it AS HTML. This can
> // result in cross site scripting.
> I wonder how to tell?
I think that the comment is partially or completely wrong.
As one can easily verify, if the server reports "Content-Type:
text/plain" the data is displayed as plain text even if it contains
some html. There must be another layer which decides how to render
the content but this list is only a YES/NO indication.
> If you follow the references back from the definition of this variable
> it appears to end up used here:
> http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/loader/FrameLoader.cpp&exact_package=chromium&ct=rc&cd=10&q=IsSupportedNonImageMimeType&l=859
> which just indicates it's used when WebKit is deciding whether to
> inline the content or not.
>
> It seems to me like you could adjust the code in
> MimeUtil::IsSupportedNonImageMimeType to always return true for any
> text/* mime type.
I wouldn't be surprised if there were an easy override
in some config file. This issue has been mentioned for ages
on the chrome issue database, often referring at the correct
behaviour of other browser e.g. Firefox. Some relevant entries:
http://code.google.com/p/chromium/issues/detail?id=24675
http://code.google.com/p/chromium/issues/detail?id=118204
http://code.google.com/p/chromium/issues/detail?id=106150
But i remember seeing many others, some closed, some with a
long trail eventually mentioning deep security or architectural
issues as a motivation not to implement the feature.
After finding out the .local/share/mime/globs2 trick, i really
believe that those answers really meant
"I have no idea why it is so, and i am too afraid of breaking
something to even consider changing things"
Annoying but understandable given the size of the code
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120430192305.GA72227>