Handling of incorrect MIME types

Post by **alanjstr** » August 11th, 2003, 12:23 pm

According to the bug I read recently, the problem is where the extension hooks into the code. After some analysis, the code needs to be rewritten a bit so as to not break other things in exposing the hook.

Dunderklumpen · Post by **Dunderklumpen** » August 11th, 2003, 12:56 pm

JeroenV wrote:I don't think it should be solved like that, that's solving an annoyance with another annoyance. I think it should go into the core, for usability's sake. People really aren't going to search for an extension solving this.

Why can't it be done the way Konqueror does it: when it gets a text/plain mimetype it asks if it should be opened with Kate (a text editor) or if it should be downloaded. It also has a "remember this decision" checkbox, so it can be swithed off. That's not too hard to get into Firebird/Mozilla, is it?

This will simply not be done since it´s one of the main features/goals for the whole project is to create a standard compliant browser. Firebird is, standard complaint, on this as it is right now. So, in order to get this into the core means that the roadmap and a vital and important goal for the whole project has to be rewritten. Do you actually think that is the best solution and do you actually think that developers will do that?

I don´t, and I don´t think it should be done either. Also - extensions are a main feature of Firebird. That´s one really good thing that separates it from other browsers. If people do not get that... well they have just grasped half of what Firebird is really about :-)

.

Pussycat · Post by **Pussycat** » August 11th, 2003, 12:58 pm

Dunderklumpen wrote:
We are not talking about getting the solution into the core. This should be solved with an extension or a plugin.

I completely disagree.

Dunderklumpen · Post by **Dunderklumpen** » August 11th, 2003, 1:03 pm

Pussycat wrote:
Dunderklumpen wrote:
We are not talking about getting the solution into the core. This should be solved with an extension or a plugin.

I completely disagree.

Read my other reply - this is what the whole projects is about. The browser is supposed to stick to standard and I see little or no chance of ever getting the developers giving that up. And, in my opinion, they should´nt either.

JeroenV · Post by **JeroenV** » August 11th, 2003, 3:24 pm

Dunderklumpen wrote:
JeroenV wrote:I don't think it should be solved like that, that's solving an annoyance with another annoyance. I think it should go into the core, for usability's sake. People really aren't going to search for an extension solving this.

Why can't it be done the way Konqueror does it: when it gets a text/plain mimetype it asks if it should be opened with Kate (a text editor) or if it should be downloaded. It also has a "remember this decision" checkbox, so it can be swithed off. That's not too hard to get into Firebird/Mozilla, is it?

This will simply not be done since it´s one of the main features/goals for the whole project is to create a standard compliant browser. Firebird is, standard complaint, on this as it is right now. So, in order to get this into the core means that the roadmap and a vital and important goal for the whole project has to be rewritten. Do you actually think that is the best solution and do you actually think that developers will do that?

Sticking to standards is good, until it gets to the point where it becomes ridiculous. Strictly speaking, FB shouldn't render pages that don't include a doctype, ignore <blink> and <marquee>, ignore the "_new" value on the target attribute etc. But those things were included too. So why not include mime-type checking?

Sacrificing usability because of standards is IMO not a good choice if Firebird wants to become successful. I know the problem lies with badly configured servers but this is how the internet is today, we can't just ignore that.

SuperJeff · Post by **SuperJeff** » August 11th, 2003, 3:50 pm

Pussycat wrote:Has anyone yet made a vote on MIME type handling? It seems like the the devs want it to be done properly and most of the users don't.

I would like to have guessing on by default and have an option (in about:config) or extension to disable it.

Or all vore for bug 135411.

From what I understood, everytime there has been a bug mentioned for this it is marked as wont fix or not a bug. Its really silly, because like JeroenV points out Firebird supports a lot of non-standard features, and all I am asking for is an option to enabled mime-type guessing or to specify how to handle all mime types (ie text/plain). Even if the option is disabled by default I would be happy. I don't care if its an extension or built in (tho it sounds like built in would be more practical from a speed perspective), but there should be some sort of work around available.

scratch · Post by **scratch** » August 11th, 2003, 5:37 pm

JeroenV wrote:Strictly speaking, FB shouldn't render pages that don't include a doctype, ignore <blink> and <marquee>, ignore the "_new" value on the target attribute etc. But those things were included too. So why not include mime-type checking?

the standard doesn't say that you can't do those things, it just doesn't say you have to do them. the standard actually says that you have to accept the mime type sent by the server. see the difference?

SuperJeff · Post by **SuperJeff** » August 11th, 2003, 11:25 pm

scratch wrote:
JeroenV wrote:Strictly speaking, FB shouldn't render pages that don't include a doctype, ignore <blink> and <marquee>, ignore the "_new" value on the target attribute etc. But those things were included too. So why not include mime-type checking?

the standard doesn't say that you can't do those things, it just doesn't say you have to do them. the standard actually says that you have to accept the mime type sent by the server. see the difference?

Well then how 'bout a little dialog box that says "The mime type for the specified document is text/plain, but Firebird has detected that it contains binary characters. Would you like to view it as a text/plain file anyway?" with a "Don't ask me this in the future" checkbox. This way we are accepting the mime type but giving the user an option to deal with inproperly configured servers.

Paradox52525 · Post by **Paradox52525** » August 11th, 2003, 11:45 pm

That's exactly what I proposed quite a while ago, but again no one actually did anything. There's a thread here:

http://forums.mozillazine.org/viewtopic.php?t=18122

where an extension to detect binary characters in plaintext is being worked on. Currently you can't actually use it though (it's just a testbox you can put a link in) and the detection is far from perfect, but it definetely shows promise. Maybe if someone can actually come up with working code that can detect binary characters in text/plain URLs the devs might soften a bit as to putting it in the core with a dialog like SuperJeff suggested. However since it is technically against standards and extension might still be a better idea. Frankly I'd be happy with either provided there's a working solution. This is a *very* annoying problem, and it's noticable enough to non-powerusers that it could harm Mozilla's reputation with new users.

Dunderklumpen · Post by **Dunderklumpen** » August 12th, 2003, 12:25 am

JeroenV wrote:
Sticking to standards is good, until it gets to the point where it becomes ridiculous. Strictly speaking, FB shouldn't render pages that don't include a doctype, ignore <blink> and <marquee>, ignore the "_new" value on the target attribute etc. But those things were included too. So why not include mime-type checking?

Sacrificing usability because of standards is IMO not a good choice if Firebird wants to become successful. I know the problem lies with badly configured servers but this is how the internet is today, we can't just ignore that.

The question is - do you think that the developers will abanded one of the main goals for the project?

Dunderklumpen · Post by **Dunderklumpen** » August 12th, 2003, 12:27 am

SuperJeff wrote:Well then how 'bout a little dialog box that says "The mime type for the specified document is text/plain, but Firebird has detected that it contains binary characters. Would you like to view it as a text/plain file anyway?" with a "Don't ask me this in the future" checkbox. This way we are accepting the mime type but giving the user an option to deal with inproperly configured servers.

Excellent suggestion - same type of solution as with downloads - only done by an extension.

JeroenV · Post by **JeroenV** » August 12th, 2003, 1:27 am

Dunderklumpen wrote:The question is - do you think that the developers will abanded one of the main goals for the project?

What's the point in sticking to standards if they don't work in practice? I thought firebird was for end users? End users don't care about standards, they want a good working browser. If IE downloads a file correctly while firebird shows it as a textfile, IE seems to work better for them. It's sad, but it's the truth.

Dunderklumpen wrote:
SuperJeff wrote:Well then how 'bout a little dialog box that says "The mime type for the specified document is text/plain, but Firebird has detected that it contains binary characters. Would you like to view it as a text/plain file anyway?" with a "Don't ask me this in the future" checkbox. This way we are accepting the mime type but giving the user an option to deal with inproperly configured servers.

Excellent suggestion - same type of solution as with downloads - only done by an extension.

Extensions should extend functionality, not "fix" something. New users won't be bothered with searching for an extension for something that's basic in their eyes. I think it should go into the core, with a pref to disable it (but on by default).

Dunderklumpen · Post by **Dunderklumpen** » August 12th, 2003, 2:35 am

JeroenV wrote:
Dunderklumpen wrote:The question is - do you think that the developers will abanded one of the main goals for the project?

What's the point in sticking to standards if they don't work in practice? I thought firebird was for end users? End users don't care about standards, they want a good working browser. If IE downloads a file correctly while firebird shows it as a textfile, IE seems to work better for them. It's sad, but it's the truth.

You did´nt answer the question....

JeroenV wrote:Extensions should extend functionality, not "fix" something. New users won't be bothered with searching for an extension for something that's basic in their eyes. I think it should go into the core, with a pref to disable it (but on by default).

There are several extensions alredy out there that "fix" things.

Fibble - restores the Mozilla Firebird name back in the title
MozEX - a workaround for Linuxuser to get the mailto protcol to work. Use the editor of your choice as source viewer and more.
Alternate Stylesheet Switcher
Autocomplete Disabler
Close Other Tabs
Copy Image
Fb Window Icon Adder

and there are many more extensions that "fix things" - not all in the list are valid right now since bugfixes have solved some of the problems in the browser wich makes the extensions somewhat obsolete but there are many extensions that solves problems/add functionality.

And again - it does not matter what you, I or anybody else thinks about this as long as one of the main goals for the whole project is to create a standard compliant browser.

Please do not switch focus. Instead of discussing a way to get around this you´re disussiong wether this should be in the core or not. Unless you really think that the developers will rewrite the roadmap, abanded an important goal for the whole project the discussion is rather pointless since that simply will not happen.

A main feature of Firebird are the extensions and as things are right now that´s also the only possible way of getting this "fixed". That or a plug-in. And if the extension works, if it gets popular - what´s saying it will not be included in the distribution package?

JeroenV · Post by **JeroenV** » August 12th, 2003, 3:34 am

Dunderklumpen wrote:
JeroenV wrote:
Dunderklumpen wrote:The question is - do you think that the developers will abanded one of the main goals for the project?

What's the point in sticking to standards if they don't work in practice? I thought firebird was for end users? End users don't care about standards, they want a good working browser. If IE downloads a file correctly while firebird shows it as a textfile, IE seems to work better for them. It's sad, but it's the truth.

You did´nt answer the question....

Yes I did. The goal is to make a standards compliant browser, but what's the point of making a standards compliant browser if it's not uasable?

The Mozilla Firebird 1.0 Roadmap says "Our target for our 1.0 release is "best of breed" browser product on Windows and Linux". IMO, if they want FB to be the best browser on those platforms they will have to implement this feature. This is somthing FB will lose users with, and I don't think we're in a position where we can afford that.

I don't want to drop standards, but I think they should bend them a little on this one. Firebird is a superior product, please don't ruin it like this...

Dunderklumpen wrote:
JeroenV wrote:Extensions should extend functionality, not "fix" something. New users won't be bothered with searching for an extension for something that's basic in their eyes. I think it should go into the core, with a pref to disable it (but on by default).

There are several extensions alredy out there that "fix" things.

Fibble - restores the Mozilla Firebird name back in the title
MozEX - a workaround for Linuxuser to get the mailto protcol to work. Use the editor of your choice as source viewer and more.
Alternate Stylesheet Switcher
Autocomplete Disabler
Close Other Tabs
Copy Image
Fb Window Icon Adder

Most of these things will eventually end up in the core. I don't think FB 1.0 will ship without an icon for example. The reason for these extensions is because FB is still beta software, and we need them to make the browser usable for some of us. That's fine for now, but if we still got to use these extensions when we get to 1.0 there's something seriously wrong.

Dunderklumpen wrote:Please do not switch focus. Instead of discussing a way to get around this you´re disussiong wether this should be in the core or not. Unless you really think that the developers will rewrite the roadmap, abanded an important goal for the whole project the discussion is rather pointless since that simply will not happen.

If the goal of the project is too far from reality, well, maybe it IS time to review it.

Dunderklumpen wrote:A main feature of Firebird are the extensions and as things are right now that´s also the only possible way of getting this "fixed". That or a plug-in. And if the extension works, if it gets popular - what´s saying it will not be included in the distribution package?

If it's included with the distribution package, why not include it in the core then? It'll be faster, smaller, and the result will be the same.

Maybe we should stop the discussion about including it here, before it becomes a flamewar. But I hope developers will understand the need for this feature.

Dunderklumpen · Post by **Dunderklumpen** » August 12th, 2003, 4:02 am

JeroenV wrote:Yes I did. The goal is to make a standards compliant browser, but what's the point of making a standards compliant browser if it's not uasable?

Do your think that the developers will abanded the goal to make the browser standard complaint?
Simple answer - yes or no?

JeroenV wrote:Most of these things will eventually end up in the core. I don't think FB 1.0 will ship without an icon for example. The reason for these extensions is because FB is still beta software, and we need them to make the browser usable for some of us. That's fine for now, but if we still got to use these extensions when we get to 1.0 there's something seriously wrong.

You must have missed something when it comes to Firebird - extensions are one of it´s main features.

JeroenV wrote:If it's included with the distribution package, why not include it in the core then? It'll be faster, smaller, and the result will be the same.

I´m starting to get the Catch 22 feeling here.........