Open Bug 57342 Opened 25 years ago Updated 8 months ago

Add "View as Text/HTML/..." option for unknown mime content-type

Categories

(Firefox :: File Handling, enhancement, P3)

Product:
Firefox
Component:
File Handling
Type:
enhancement

Tracking

()

People

(Reporter: pohl.longsine, Unassigned)

References

(Depends on 1 open bug, Blocks 5 open bugs,
URL
)

Details

(Keywords: arch, parity-opera)

Attachments

(7 files, 5 obsolete files)

patch v0.1
31.08 KB, patch
Details | Diff | Splinter Review
Text File with 00 chars
4.32 KB, text/plain
Details
ui hack for testing
4.23 KB, patch
Details | Diff | Splinter Review
Toolkit ui hack for testing
3.55 KB, patch
Details | Diff | Splinter Review
backend patch, v4 updated
36.93 KB, patch
Details | Diff | Splinter Review
PoC modal dialog
12.46 KB, patch
Details | Diff | Splinter Review
screenshot of browser file reception dialog that has a grayed out "remember" item
14.33 KB, image/png
Details
It appears that there is no way to tell mozilla to display documents of type text/* (other than text/plain) to display right in the browser window. I would like to browse source code files (text/x-java, for example) right in the browser, but instead I am presented with an open-using/save panel. Neither of these two options is the desired choice. I could not find a way to tell mozilla to treat text/x-java the same way it treats text/plain.
over to XPApps
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
QA Contact: sairuh → shrir
pohl@screaming.org - you couldn't point us at a URL served as text/x-java or similar, could you? Which bits of UI have you looked in to find how to set this, and where would you expect such a function to be? Gerv
http://screaming.org/~pohl/ServletWithCache.java The above link should be a suitable example. As for where the function should be, my instincts led me to the Edit-->Preferences-->Navigator-->HelperApplications where I attempted to add a mapping for ".java" of type text/x-java. In the panel where you "add" or "edit" the mapping, I would imagine that there would be a checkbox (for text/* types) that says "display within browser window", and perhaps checking this checkbox would also disable the widgets for selecting the helper application.
In addition to a checkbox in the edit/add panel, perhaps there should be a settable default in the HelperApplications panel itself that says something to the effect of "by default, documents of type text/* should be (*) displayed within the browser (*) saved to disk" with radio-buttons to select. them.
pardon the spam: reassigning these remaining xp apps bugs of don's to vishy for the time being. hope that's okay!
Assignee: don → vishy
Changed summary. Marking as NEW so someone will either mark it as WONTFIX or INVALID.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: mime and helper settings inadequate → [RFE] Mime and Helper settings
Keyser Sosez!? He's comming for me! Ok, levity aside, is there a reason this shouldn't be addressed? WONTFIX and INVALID seem premature. Changed severity to "enhancement".
Severity: normal → enhancement
nav triage team: Yes, WONTFIX and INVALID seem a bit much. We'll just keep it in the database for eons. ;-) Very nice to have, but don't think we'll have time to get to this for beta1, marking nsbeta1-
Keywords: nsbeta1-
I believe the logic that controls this kind of thing is presently in: uriloader/exthandler/nsExternalHelperAppService.cpp I also believe that profile/defaults/mimeTypes.rdf has fields that may or may not allow for this already, but I don't know because even after asking for several months that database has not yet been documented. Sigh.
Depends on: 61408
Depends on: 58811
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
Depends on: 52441
Blocks: 78106
Summary: [RFE] Mime and Helper settings → Allow arbitrary MIME types to be treated as plain text
This is longstading default behavior, to map text/[unknown type] to text/plain -- this is NOT a feature request! Please put it back on the radar. Thank you!
Another thing: should this be assigned to bzbarsky@mit.edu (Boris Zbarsky) since he is working on bug 52441?
No longer depends on: 58811, 61408
Boris: please read this one. Thank you! Saruh: I am unable to change the "enhancement" and "future" fields (that might be a good thing ;-) but not in this case.) Would you please? Also please change the summary to "default unrecognized text/* types as text/plain" from "Allow arbitrary MIME types to be treated as plain text" Thank you!
jps: This bug doesn't seem to relate to that bug. So no, unless bz wants this bug it shouldn't be forced on him. Since vishy isn't interested, i'll try an alternative tact: Ask for suggestions about a UI. Once we get a UI spec we can ask someone to implement it.
Assignee: vishy → mpt
Component: XP Apps → User Interface Design
Keywords: arch, helpwanted, mozilla1.0
OS: Linux → All
QA Contact: shrir → zach
Target Milestone: Future → ---
There's a comment in bug 52441 about giving the helper app dialog a "show in browser" option. I feel that that would be the best thing to do with this as well. I agree with timeless -- we should decide on a UI for this before implementing anything. I may poke around a bit at the back end to see what's feasible (I don't know whether the external handler service can call back into the browser to display stuff in the browser window....) mpt? Thoughts?
Yes -- once we replace the current Unknown Type alert with one that uses buttons for commands (avoiding the unfortunate use of radiobuttons as commands), those buttons could be: (Save As ...) (View as Text) ( Cancel ) ((Open With...))
And what if someone wants to view a document as html or xml? [this is actually a real need since many webservers manage to mess up user's mime types] I suppose (View as ...) would work. (Treat as ...) might also [but someone will say they don't know what treat means, well... you don't view sound so ... Handle as ...?]
There's a certain point where you have to just give up and make the user do a bit more work (in this case, save the file with .html extension and open it locally), rather than trying to handle everything in the alert. Having `Handle As ...' would be annoyingly incomprehensible for the majority of users who saw this alert regularly. Already, with `View as Text', we'd be offering them more power than any other browser I've seen. --> Networking
Assignee: mpt → neeti
Component: User Interface Design → Networking
QA Contact: zach → benc
Target Milestone: --- → Future
mpt, what's the bug for the new "Unknown Type" dialog? I've poked a bit and all that needs to happen to "view as text" is the following: 1) reset the mime type to text/plain in the MIMEInfo 2) reset the preferred handler to nsIMIMEInfo::handleInternally both can be done from Javascript (it's a scriptable interface) so this can be done in the dialog without too much trouble in my opinion...
Blocks: 86640
*** Bug 87301 has been marked as a duplicate of this bug. ***
No longer blocks: 86640
I one-shot solution (via the unknown type dialog) would be fine, but I'm more interested in a permanent solution, i.e. an option in the preferences to always show type "foo/bar" raw (as text). I think mozilla should ship with an entry for text/* that has this option enabled. Treating any text subtype that is not known as text/plain is actually MIME standard behaviour. I don't consider that part an enhancement. Example: http://people.debian.org/~jaqque/debian-issue.sh returns text/x-sh, which mozilla should display as text.
If there is a snippet of MIME specs that shows that, please add it here. It's futured, so we need a contributor if this is going to happen.
The "MIME specs" suggest that "Text" without a subtype should be analyzed to determine if a multibyte set is in use. I don't know whether there is a Unicode-aware version of file(1) aroud to peruse the logic yet, but that is one place to start looking. Boris is also correct that type specification should be requested when an unknown type is encountered. So, I like this suggestion from tux@centrum.cz (Martin Petricek) from duplicate bug 87301, quoted below -- When mozilla encounter unknow content-typ a dialog will appear: [ ] use default action [ ] use different action [ ] save to disk [ ] open with application _______ -It might be very useful to add something like- [ ] view as text/plain -- or -- [ ] treat as [text/plain ] to the dialog (so i can force this to be either text/plain or text/html, etc ...) and maybe add it also to preferences so this could be settable also as default action This will help to wiew content-types like netscape/proxy-autoconfig, etc ... like plain text
I don't know what "specs" James is talking about. I was alluding to RFC2046. Specifically, section 4.1. of that says: Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Such formatted textual data should be represented using subtypes of "text". Later, in 4.1.4: Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset. Unrecognized subtypes which also specify an unrecognized charset should be treated as "application/octet-stream". My take is that, when encountering "text/my-doc-format; charset=us-ascii", to be compliant, Mozilla must allow display of this as if it were text/plain. It should (IMHO) treat text/xyz with a missing charset as if charset were UTF-8 (this makes most cases work), and it should allow MIME types other than text/* to be displayed raw, if that isn't much work.
*** Bug 100080 has been marked as a duplicate of this bug. ***
*** Bug 95028 has been marked as a duplicate of this bug. ***
*** Bug 125847 has been marked as a duplicate of this bug. ***
I can't view any of the text files on: http://www.samba.org/ftp/unpacked/netfilter/userspace/extensions/ This is quite bad. Doesn't it make sense to display text/<unknown> as text/plain? The files on that page are all served as text/x-csrc. I had to save a bunch to disk and use a console to view them.
Fixing summary or I'll never be able to find this bug again.
Summary: Allow arbitrary MIME types to be treated as plain text → Allow arbitrary MIME content-types to be treated as plain text for viewing
Everyone agrees this would be good. This at this point requires architecture changes to the URILoader -- once we determine that we have no content viewer for the data we seeem to pass it off to the external helper app handler and have no way of getting it back into core layout again even if the external helper app handler jumps through hoops. I'm working on some stuff in there this weekend.... if I fix it, good. If not, I would strongly recommend passing on this for 1.0 -- this is the sort of arch change that should bake on the trunk and in milestones for a while.
OK. There are actually two separate issues here: 1) Have a way to set user preferences to handle a particular type as plaintext. I have the back end of this working in my tree (just reset the type on the channel to text/plain and punt the load back to the originating docshell). 2) Have a way for the user to select "view as text" from a helper app dialog that comes up for an unknown type. Here the problem is that the data is already being sent to dist at this point and the original docshell is no longer in the middle of a load -- it thinks it's done. I have no idea how to solve #2 without completely rearchitecting all the helper app stuff...
Good points, Boris. How about designating one app as the external text viewer, and giving it a pick-helper-app button of its own? The analogous thing, for the faraway ideal of input helper apps, would be to have an editor specified as the general INPUT TYPE=FILE ACCEPT=(unrecognized) situation. There, you could have different editors depending on the major type name. This suggests the question for when the external text "viewer" is offered. In the traditional situation, View Source..., there was a time when the OS text selection and copy was disabled on windows. Not a user-centered feature, and a not-very-best laid plan that went astray to the point of absurdity. To add insult to injury, someone came up with the idea of putting "Open Link in Composer" next to "Open Link in new Window." Many of us with control over content-sensitive menus might consider a seperator there. In short, I want to be able to open anything, even binary files, in any editor I specify, but I don't want to do so when I am trying to open it in a new navigator window. I suggest a new menu item, at least ten pixels from "open link in new window" with "open in ________" where the blank is filled from a preference. Maybe multiple such global viewers. And, when I click on something purporting to be text/x-quadruple-byte-klingon, I want to chose between all my global viewers, and navigator, and something else to be specified in further dialog. And if I choose the latter option, I want to be able to add the selected application to be the default for the specific type, the default for unrecognized major types -- e.g. text/(unrecognized) -- or a new global viewer to add to my context-sensitive menu.
*** Bug 21985 has been marked as a duplicate of this bug. ***
Summary: Allow arbitrary MIME content-types to be treated as plain text for viewing → Add "View as Text" option for unknown mime content-type
Summary: Add "View as Text" option for unknown mime content-type → [RFE] Add "View as Text" option for unknown mime content-type
*** Bug 142451 has been marked as a duplicate of this bug. ***
-> file handling
Assignee: neeti → law
Component: Networking → File Handling
QA Contact: benc → sairuh
*** Bug 144219 has been marked as a duplicate of this bug. ***
*** Bug 144960 has been marked as a duplicate of this bug. ***
*** Bug 156487 has been marked as a duplicate of this bug. ***
I'd like to see the "View As Text" option for mime types other than text/*. For example, right now I can view C source files but not TCL source files. I checked, and .c files are sent with a mime-type of text/plain, while .tcl files are sent with a mime-type of application/x-tcl. Don't ask me why... However, since both are actually plain text, it'd be nice to be able to view both in Mozilla. Someone suggested forking an external viewer/editor. This does work (I tried it for the TCL files), but it isn't as nice as seamlessly viewing in Mozilla along with other file types.
Is there another non-RFE bug for being able to view files such as these? If not, this should be changed to a non-RFE bug. It's basic functionality that's broken.
That's what I was thinking when I reported the bug. To me it's just broken. I marked it RFE because I didn't want someone to just declare the bug 'invalid' and lose track of it.
See also bug 108313, Mozilla should display text/foo (where foo is unknown) as text by default instead of trying to download it.
*** Bug 163670 has been marked as a duplicate of this bug. ***
*** Bug 108313 has been marked as a duplicate of this bug. ***
*** Bug 166329 has been marked as a duplicate of this bug. ***
Related: Bug 11521, View as different media type support.
Summary: [RFE] Add "View as Text" option for unknown mime content-type → Add "View as Text" option for unknown mime content-type
*** This bug has been marked as a duplicate of 11521 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reopening, since this, unlike bug 11521, may actually be fixable in a reasonable manner...
Blocks: 11521
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Hmmm... Boris, what's about bug 156788 ? Let's reopen it also...
Nope. That's precisely an example of the "really hard to solve" case that needs a full fix to bug 11521. Note that this bug is talking about types we do _not_ handle internally, for which things are much simpler ("all" we have to do is in the helper app code reset the type to something we handle and somehow kick the load back to the browser). In the case of types we _do_ handle we need to perform some sort of special reload or something like that... you get a number of nasty cache-related issues, etc.
QA Contact: sairuh → petersen
Depends on: 176919
Blocks: 191000
*** Bug 197579 has been marked as a duplicate of this bug. ***
*** Bug 213316 has been marked as a duplicate of this bug. ***
*** Bug 214313 has been marked as a duplicate of this bug. ***
*** Bug 215706 has been marked as a duplicate of this bug. ***
Someone has quoted RFC2046. There is also a suggestion in RFC1341 about what to do with text/strange-unknown-format and similar MIME types: >In general, the top-level Content-Type is used to declare >the general type of data, while the subtype specifies a >specific format for that type of data. Thus, a Content-Type >of "image/xyz" is enough to tell a user agent that the data >is an image, even if the user agent has no knowledge of the >specific image format "xyz". Such information can be used, >for example, to decide whether or not to show a user the raw >data from an unrecognized subtype -- such an action might be >reasonable for unrecognized subtypes of text, but not for >unrecognized subtypes of image or audio. I think there is a third 'strand' to this bug that is separate from the two issues mentioned by Boris Zbarsky. He mentioned user preferences to handle a particular type as plain text, and an extra 'view as text' option for a helper dialogue box. But for a MIME type that is text/something, shouldn't the browser just display the document immediately as it does for text/plain? This should not require any UI spec - no extra dialogue boxes or prompts are needed, all that happens is for text/* to be treated the same way as text/plain unless some more specific handler is set up. Having a preferences box to treat a particular type as plain text (and not limited to just text/* MIME types) would be nice; an extra 'view as text' option in the helper app dialogue box would also be nice. But neither of these is a prerequisite for fixing the current default behaviour, so that a text/* document displays as text rather than being treated as a wholly unknown type.
So the first time we encounter text/rtf we should just dump it out as plaintext and not give the user a chance to set up a reasonable handler for that type? That's not reasonable. In fact, that whole section of the RFC is incredibly bogus in my mind, since most text/* types are in fact not human-readable (this includes text/html and its ilk; people who code HTML for a living by hand notwithstanding).
As Comment #55 states the RFC: >such an action might be >reasonable for unrecognized subtypes of text, but not for >unrecognized subtypes of image or audio. It says _might_ be reasonable, not should. If I try to download a text/almost-binary-whatever (such as /etc/sendmail.cf), I expect a dialog asking what to do: You are trying to view text/almost-binary-whatever content... () Save to disk... () Show in browser as text/plain () Open with program... [x] Always do the same for this type [OK] [Cancel] Just my 2 yen...
My suggestion would be to have a back-end pref with a list of types that are handled as text/plain. (My pet peeve is trying to view dtd files at w3c.org) This would save the extra pref in the ui, but still give advanced users an option to change it through about:config or the .pref file. This pref should come preloaded with things like text/css, text/tab-separated-values, application/xml-dtd, and others that are known human-readable file types.
I think it's a fair point that defaulting to show-as-plain-text would not give the user the opportunity to set up a custom handler for text/rtf or whatever. On the other hand the current behaviour does not give the user the opportunity to view a document in the browser. So you could weigh up which of the two is worse. But perhaps you don't want to do anything on this until it can be done _right_ (which I assume means an extra UI preference and a 'view in browser' option on the helper app chooser). That sounds entirely reasonable.
-> me. I have a proof-of-concept.
Assignee: law → cbiesinger
Status: REOPENED → NEW
this unfortunately includes the "part 2" patch from bug 78919 as well as the patch for bug 120045 :( sorry about that I hope the concept is still visible, which is mainly passing an nsIDispatchable to nsIExternalHelperAppService::DoContent. I'm not very good at coming up with names, so said name might suck; feel free to suggest a different one. oh, and you _do_not_ want to run a normal mozilla with this exact patch. you will be sorry if you do. (that's because it forces all externally handled content to display as text/plain, for testing purposes) next step: clean this up a bit, allow this to be called from the helper app dialog, implement ui for it
Attached patch patch v0.1 — — Splinter Review
ok, better version of the patch. Comments on this patch are welcome. Note: UI is not final yet. I'm thinking of something like this: (o) View as [Text v] with the dropdown containing: +---------------+ | Text | | Image | | HTML | | XML (maybe) | | Other... | +---------------+ Where "Other..." allows the user to manually enter a mime type. oh, btw... this patch removes pre-downloading while the dialog is up. it doesn't do cleanup that would be allowed by this change, though. guess I'll do that in another patch.
> oh, btw... this patch removes pre-downloading while the dialog is up. Please make that a separate patch, and do it first if needed for this bug. That change needs to be done somewhat carefully in the face of how stream converters work, and it will be simpler to debug the more localized changes.
> Note: UI is not final yet. > I'm thinking of something like this: > > (o) View as [Text v] > with the dropdown containing: > +---------------+ > | Text | > | Image | > | HTML | 'Web Page' would probably be more understandable for most users. > | XML (maybe) | Or maybe not. :-)
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=x-foo%2Fx-bar&disposition=inline&filename=&quote=1&justshow=1
*** Bug 221998 has been marked as a duplicate of this bug. ***
note to self, mReceivedDispositionInfo seems to be sufficient for mSuspended=TRUE, so the latter variable can maybe be eliminated
*** Bug 226595 has been marked as a duplicate of this bug. ***
URL: http://biesi.damowmow.com/mime.php?do...
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=x-foo%2Fx-bar&disposition=inline&filename=&quote=1&justshow=1
*** Bug 230252 has been marked as a duplicate of this bug. ***
*** Bug 232751 has been marked as a duplicate of this bug. ***
*** Bug 234108 has been marked as a duplicate of this bug. ***
*** Bug 236237 has been marked as a duplicate of this bug. ***
*** Bug 236623 has been marked as a duplicate of this bug. ***
Whiteboard: parity-opera
Were there any big problems with the patch? Biesi, will you be working on it? Thanks.
(In reply to comment #73) > Were there any big problems with the patch? Biesi, will you be working on it? > Thanks. yes, it breaks saving IMAP attachments, as well as saving files from some http servers. I need to find a solution for that... targeting optimistically
Target Milestone: Future → mozilla1.8beta
I might encourage this bug to also include the case of application/<unknown>+xml (or <anything>+xml?). Sometimes I'm hitting an XML MIME type that the browser doesn't explicitly handle, and receive the same type of dialog as the text/<unknown> case. In this situation, though, it's an XML document (as evinced by the +xml suffix), and Mozilla can display XML, at least in tree form. See also bug 194351.
*** Bug 210384 has been marked as a duplicate of this bug. ***
*** Bug 242124 has been marked as a duplicate of this bug. ***
comment 18 suggests that adding this enhancement would offer users "more power than any other browser I've seen" - as if that's a reason not to do it. The suggested alternative is "make the user do a bit more work" - so the user is protected from something "annoyingly incomprehensible" like a Handle As... option, and instead only has to download the silly file, open a shell window and rename the file to have a recognized extension, and go back to Moz and type in a file: url for the new file in order to view it. And remember to remove the file after. That isn't any more comprehensible or less annoying to a novice user, and if I had a novice user on a support line I'd much rather be able to say "hmm, dialog asking what to do with application/x-pdf? Yeah, just pick Handle as application/pdf, it'll be fine." I actually see things served as application/x-pdf often enough that I have an entry in MIME types for "Mislabeled Portable Document Format". :( And then there's always the occasional html/text or txt/html or other wacky content type where you see it and you know immediately what it was supposed to be but you have to go run around the block in order to view it. For UI, I'd suggest that Handle As... gives you a selection box to pick from any of the types currently known to the browser, ideally with more common ones and closest fuzzy matches to the served content type toward the top. With a tip for the Handle As button saying something like "Use if you think you know what type this document really is" I don't think it really has to be incomprehensible.
comment 62 suggests UI already. I'm quite hesitant to add more items to the list... Maybe there should be an additional one for a type guessed from the file extension, but that should be all, I think.
I disagree. This is a common enough problem, and being one where the people causing the problem, or at least capable of solving it, are generally not the ones suffering from it, and may not be open to fixing it since the people capable of actually explaining what the problem is are a very small subset of their audience, or they may not be directly contactable through the corporate bureaucracy, this merits very careful thought about how the problem can be mitigated from the client side. There are cases where a resource can be opened, will force the "Save As" dialog, and if saved and double-clicked will immediately open the browser which will render it fine. This is quite clearly a ridiculous situation! We know why it happens but the user experience is just stupid. Certainly there are a few common media types which, for a user who can see what the resource ought to be handled as, they should be able to easily override the Save As prompt and cause the resource to be opened by that built-in handler. I'm thinking here "Plain Text", "HTML", "JPEG image", "GIF image". Plus a few more. PNG, XML etc. The list isn't huge, will cut out 99.9% of erroneous mimetype problems, and if a confused user chooses the wrong thing they can always try again and are in no worse situation than they started off. Possibly this should be defaulted based on the resource "filename extension" - I can't see that being a problem (in many cases it just won't work, but is no worse than not doing so). Defaulting based on the first few bytes of the resource would be better. Possibly, if we really want to keep that dialog absolutely as simple as possible then it should be made an expandable dialog with an "Advanced/More>>>" button - I don't see a problem with that either. But there *does* need to be an escape route, because the failure mode results in far more effort than is reasonable to work around, currently. It *should* just work transparently, yes, but it sometimes doesn't and in those cases it really doesn't need to fail that badly. Choosing obvious stuff from a list is an absolute minimum. The real expert user will also want to be able to type in a literal mimetype. Hide these by default if you're really worried about scaring some users, but they ought to exist somehow. (I'd also like to point out that "unknown mimetype" is not the only problem - there are cases where the mimetype is recognised but mislabelled. In these cases it would be useful to be able to invoke something similar to the Save As dialog manually on a link. The example that springs to mind is download sites that mislabel PKZIP or Windows executable files as text/plain. In fact I'd really like to see a check for resources starting in PK or MZ and throwing a dialog saying "Are you sure you want to open this as text or HTML", but that's getting beyong the scope of this bug.)
> will also want to be able to type in a literal mimetype see the "other" part of comment 62 > like to see a check for resources starting in PK or MZ current mozilla versions check if the first 1000 bytes or so of the data contains binary content and show the helepr app dialog if so (assuming the type is text/plain). that is indeed a different bug.
Should the summary be changed from Add "View as Text" option for unknown mime content-type to something like "View as [Text|...]" option for unknown/wrong mime content-type since the discussion seems to be converging that way and not to have Text as the single, fixed option?
Summary: Add "View as Text" option for unknown mime content-type → Add "View as Text/HTML/..." option for unknown mime content-type
After almost 4 years discussing, shouldn't this bug be fixed somehow? :-(
(In reply to comment #80) > Possibly this should be defaulted based on the resource "filename extension" It's important to note that the whole concept of a "file extension" is OS- dependent and only meaningful on operating systems that determine a file's type from it's file extension. In the HTTP world and on most non-Windows OS's, a file's extension has no meaning and is opaque. This is part of why server misconfigurations are so annoying: the server- provided MIME type *should* be the final authority on what the content is. I strongly advise against following IE's behavior here and second-guessing things that look too generic. The problem is with the site, and in this case, the site author *is* using IE exclusively to test things (or isn't testing at all), which is why we're in this mess to begin with. We certainly need a way to override MIME types that are incorrect, but we should look towards correcting the problem (the server misconfiguration) first, and treat this as a temporary workaround until a real fix is performed. For that reason, none of this should be performed automatically or without notifying the user. We should NEVER do the IE thing here and *silently* use our own second-guessed MIME type in place of what *appears* to be a generic or misconfigured MIME type. I do like the idea of an "Advanced/More >" thing, and we should be able to pull this dialog up even when Mozilla has a good idea of what to do with the resource as it's currently labeled.
While I agree with David's comment 85, I note that on unix systems which don't depend on the file extension, content type-guessing programs such as file(1) are certainly allowed to use the filename in making a decision about what to report. On the other hand, those guessing programs ought to be able to get /dev/stdin correct most of the time. The filename should only be used to resolve ambiguities when it is available, and there is nothing wrong with asking the user to confirm such ambiguity resolution, except (and this case is probably rare) when it becomes an encumberance to the user being able to proceed at their customary pace. If you wanted to accommodate that, Christian, you might include a "Don't ask me to confirm such guesses again" checkbox, but I wonder how useful overall that would be.
*** Bug 246438 has been marked as a duplicate of this bug. ***
Other changes in 1.7 have broken web sites that I used in 1.6 without issues. The changes reference this as the "fix" for their breaking stuff, so I'd encourage those involved to fix this as soon as possible.
I believe this is a duplicate of bug 121498.
(In reply to comment #89) > I believe this is a duplicate of bug 121498. No; this proposes a more extensive solution. Solving this would solve that bug, but the reverse is not necessarily true. (In reply to comment #88) > Other changes in 1.7 have broken web sites that I used in 1.6 without issues. > The changes reference this as the "fix" for their breaking stuff, so I'd > encourage those involved to fix this as soon as possible. Brad Clarke, could you cite those changes/bugs, please?
After some offline discussion it was determined that the problem is with txt files with 00 in them (I'll attach one for you).
(In reply to comment #88, comment #91, comment #92) Brad, please try to use a few more words to explain what you are trying to say. What about the file attached? If you look at it from bugzilla, it will (and is) served as text/plain, so everything should work (works in 1.6 at the moment). What broke in 1.7. for you?
The file here on bugzilla even seems to open fine :/ In 1.6 it opens just fine in the browser. In 1.7 I get the download dialog with the content type showing as "text/plain" and the default application being "txtfile" (notepad). Since notepad displays the txt file fine with no formatting problems or unprintable characters, the content type from the server is "text/plain" and the extension for the file is "txt" it's very odd to me that 1.7 can't just display it. Other txt files in the same directory on the web server open in 1.7 just fine. It's being served by a very simple servlet from tomcat which you can see here: http://cvs.sourceforge.net/viewcvs.py/cruisecontrol/cruisecontrol/reporting/jsp/ src/net/sourceforge/cruisecontrol/servlet/FileServlet.java Please let me know if there is any more information I can provide.
please, keep that discussion out of this RFE. it is working as designed, and pretty unrelated to this bug. bugzilla attachments do not exhibit this behaviour, because their content-type header is neither "text/plain" nor "text/plain; charset=iso-8859-1". please discuss further issues with this in a newsgroup, private mail, or different bug. thank you.
*** Bug 248893 has been marked as a duplicate of this bug. ***
I have found that http://www.spamhaus.org/ will frequently bring up the "Save As ..." dialog. It appears that it doesn't send a Content-Type: at all, and that apparently, this is interpreted as application/octet-stream I can't always repro this; don't know if they have multiple servers or if they're changing their configuration back and forth between something which works with Mozilla and something which doesn't. In any event, I would very much like to be able to specify that it's just HTML and it should be opened in the browser and not Saved As ... anything.
Can't finally someone take a look at this? I can't understand why such simple thing can't be done for 4 (!) years ...
(In reply to comment #98) > Can't finally someone take a look at this? I can't understand why such > simple thing can't be done for 4 (!) years ... Then maybe you should try fixing it yourself? See points 1.1 and 1.2 here: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Sorry, I didn't mean any offense. I still hope this annoying bug is finally going to be fixed one day.
it is going to be fixed one day, unfortunately bug 227113 is a real problem that stands in the way of fixing it, and it's somewhat hard to fix. bug 217434 too, but less of a problem... that's why those bugs are marked as blocking this one. so this bug now has 4 more useless comments, that nobody will read. thank you very much.
I can't follow the other bugs (I simply do not understand them), however what I really wonder is why we need this huge discussion in the first place. Excuse my dumb mind, but why can't it be done some way like this: .configfile: # treat-these-mimes-as-plain-text ttmapt: text/x-sh, text/x-java <empty by default> browser mime handler: [... handling file with $mime ...] if(contains($ttmapt, $mime)) $mime = text/plain; [ ... go on with $mime handling ...]
Prompted by the previous comment, I looked into the "depends on" links to bugs which are not yet fixed. Not a single one of them makes much sense to me. Maybe I'm dense, but even if so, it would be useful to document exactly why this bug depends on bug 69938 (downloaded files are needlessly downloaded to a temporary location), bug 217434 (IMAP suspend/resume issue [sic]), and bug 227113 (stream converter suspend/resume issue ... what's a stream converter anyway?), or else remove those dependencies. In fact, while I doubt it will do much good, I'm taking the liberty to (attempt to) remove them here and now.
No longer depends on: 69938, 217434, 227113
arg, can you stop touching the dependencies of my bugs? summary of the issue is: we want to offer the "view as ..." option in the helper app dialog (as the summary of this bug says). this means we want to stop the networking code from continuing sending us data while the dialog is up, so that we can send it to the appropriate other component in the mozilla code instead. This means Suspend(), the function that means "do not send data until Resume() is called", needs to work reliably. hence the dependencies. > Excuse my dumb mind, but why can't it be done some way like this: well, technically that'd be doable. practically, no user would be able to discover it...
Depends on: 69938, 217434, 227113
Woah, woah. This shouldn't require us to break the download streaming. It doesn't break it in Opera, why would it break it in Mozilla?
(In reply to comment #62) > patch v0.1 So about a year ago there was a preliminary patch for this bug that seems to do everything /I/ want it to do. I'm a newbie here; can someone please point me to (preferably) a binary containing that patch, or else instructions on how to get sources for and build the patched browser? I know several other people who would like this, too.
(In reply to comment #105) > Woah, woah. This shouldn't require us to break the download streaming. It > doesn't break it in Opera, why would it break it in Mozilla? intersting. how does opera do it, especially in case of gzipped content? does it read half of the data from the file again? (In reply to comment #106) > on how to get sources for and build the patched browser? I know several > other people who would like this, too. http://www.mozilla.org/build/
Another example of a very common server type-mislabeling trick that inconveniences the user happens with Mailman-maintained mailing list archives. These archives always have a monthly (or some other period) archive file that is gzip'd text. It usually comes labeled as: Content-Type: application/x-gzip instead of the correct: Content-Type: text/plain Content-Encoding: gzip and as simple as the problem is, there is no way I've ever found to get Mozilla to show the text instead of insisting on saving to file. This example is Mailman bug 905910: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=905910&group_id=103 ... but even if it gets fixed in Mailman, lots of Mailman sites out there will surely be sending mislabeled files for a long time after, so the browser needs some way for the user to cope.
>> Woah, woah. This shouldn't require us to break the download streaming. It >> doesn't break it in Opera, why would it break it in Mozilla? > > intersting. how does opera do it, especially in case of gzipped content? does > it read half of the data from the file again? Do you have a test case that I can check? I'm not familiar with this corner of HTTP enough to reliably create it myself. (Alternatively, explain exactly what I should test using HTTP headers and content and I'll try to do it myself.) I'm not sure exactly how Opera does it, but many possibilities come to mind, such as streaming the data into memory instead of disk, streaming the data into the cache unchanged until a final location is picked (and then decoding it on copy instead of just moving it, if that is necessary), or saving the file data gzipped and then uncompressing it if required.
Just find a link of .tar.gz file, left click the link. Mozilla will ask you save it to disk or open it. 1)If select save, you will find the file you saved was gunzipped but still named as .tar.gz. 2)If select open, you will find it fail to be opened, and find something in your /tmp. Really annoy.
(In reply to comment #109) > Do you have a test case that I can check? I'm not familiar with this corner of > HTTP enough to reliably create it myself. (Alternatively, explain exactly what I > should test using HTTP headers and content and I'll try to do it myself.) OK... hm... try this: - name the file foo.html.gz - send as: Content-Type: text/html Content-Encoding: gzip Content-Disposition: attachment - content should be gzipped, of course. Expected behaviour: When I "View as HTML" or "View in Browser" or something, I want to see the ungzipped HTML, of course. When saving, I want the .html.gz file contain gzipped content. When I click "Open using [iexplore.exe ] [Choose...]" I expect the content to be decoded before passed to msie. .tar.gz is probably not such a good example; you won't want a "view in browser" there. but maybe testing w/ helper apps is a good idea too: name foo.tar.gz content-encoding: gzip content-type: application/x-tar Saving to a file should absolutely not decode. Opening in an application probably should decode, with appending .tar... foo.doc content-encoding:gzip content-type:application/msword that should always decode.
Gleep! I'm not sure I like the sound of having a dozen ad-hoc rules for when to decode or not and what to do with file extensions--especially because as far as http is concerned, the Content-Type and Content-Encoding headers are everything and filename extensions are invisible to the standard. I would suggest two very simple rules to apply in perfect uniformity, regardless of the type of data. 1. If it's to be processed/displayed internally, then of course undo the encoding. 2. If it's to be saved to a file, and has a non-null Content-Encoding that Mozilla knows how to undo, give the user radiobuttons on the save dialog: This file was sent with the encoding: gzip O save in this encoding O undo encoding and save Then you can add file extension *heuristics* if you want, say for example if the encoding is gzip and the suggested name in the Save dialog ends in .gz then change the suggested name to without the .gz ... that makes these convenience suggestions that the user sees in the dialog and has the choice to accept, not a plethora of rules that get applied for various content types and make the user try to figure out what happened. As for what to do when invoking a helper: the real answer is probably allow each helper definition to include an Accept-Encoding list. If a file comes in an encoding the helper accepts, Moz passes the file unchanged. If the helper does not accept the encoding but Moz knows how to decode it, then Moz decodes. Otherwise, need to ask the user what to do. An alternative to accept-encoding list per helper is for helpers to be a relation indexed by (content-type, encoding). That way you could support a helper that can accept a certain encoding but needs maybe different command line options to do it, because the entry for that (type,encoding) pair would be able to have its own command line. But I'm not sure all of these considerations need to be handled for THIS bug....
Blocks: 258012
Blocks: 266410
solution: never offer this option when we decided not to apply encodings. that allows us to easily do this.
Keywords: helpwanted
Comment on attachment 165149 [details] [diff] [review] backend patch this does not provide a good solution for the frontend to figure out whether a certain mime type is supported... do you think I should add such a method to nsIDispatchable? Or should the frontend figure that out for itself (eg by querying the Gecko-Content-Viewers category)? I'm not sure currently what I prefer...
Attachment #165149 - Flags: review?(bzbarsky)
this is a patch to the UI that I used for testing; it is totally unsuitable for checkin, but it shows how the backend can be used.
I'll try to get to this in the next few days...
Blocks: majorbugs
Comment on attachment 165149 [details] [diff] [review] backend patch forgot to change the uuid...
Attachment #165149 - Attachment is obsolete: true
Attachment #165149 - Flags: review?(bzbarsky) → review-
*** Bug 272088 has been marked as a duplicate of this bug. ***
Comment on attachment 165908 [details] [diff] [review] backend patch v2 >Index: uriloader/base/nsURILoader.cpp >+NS_IMETHODIMP nsDocumentOpenInfo::ReDispatch(const nsACString& aMIMEType, This wants to NS_PRECONDITION aData and NS_PRECONDITION aRequest, right? Also, why is it ok to have an aRequest here that's not a channel? When would that happen, exactly? URILoader in general only handles channels, and we really do want a channel here to be able to do SetContentType... >+ // Save type and stream listener "save old type and stream listener in case we fail to redispatch", right? >+ rv = aData->Available(&count); >+ // XXX what if that failed? We cancel aRequest with rv? That would make the most sense... >+ rv = m_targetStreamListener->OnDataAvailable(aRequest, nsnull, aData, 0, count); Hmm... I guess this is an OK context to pass, since there's really no better one in sight, and we _did_ open this channel ourselves with a null context, huh? Could you write a comment to that effect? > nsCOMPtr<nsIExternalHelperAppService> helperAppService = > do_GetService(NS_EXTERNALHELPERAPPSERVICE_CONTRACTID, &rv); >- if (helperAppService) { >+ if (!aAllowExt) { >+ rv = NS_ERROR_NOT_AVAILABLE; >+ } else if (helperAppService) { I think this would be clearer written as: nsCOMPtr<nsIExternalHelperAppService> helperAppService; if (allowExt) { helperAppService = do_GetService(NS_EXTERNALHELPERAPPSERVICE_CONTRACTID, &rv); } else { rv = NS_ERROR_NOT_AVAILABLE; } if (helperAppService) { ... > nsDocumentOpenInfo::TryContentListener(nsIURIContentListener* aListener, >- nsIChannel* aChannel) >+ nsIRequest* aRequest) I'm not so enamored of that change, for the same reasons as apply to the first comment on this patch... >- NS_PRECONDITION(aChannel, "Must have a channel"); >+ NS_PRECONDITION(aRequest, "Must have a channel"); If the change _is_ made, please fix the assert text. >Index: uriloader/exthandler/nsExternalHelperAppService.cpp >+NS_IMETHODIMP nsExternalAppHandler::GetCanHandleAs(PRBool* aCanHandleAs) This would be better named GetCanCallHandleAs, I think... > NS_IMETHODIMP nsExternalAppHandler::OnStopRequest(nsIRequest *request, nsISupports *aCtxt, >- mRequest = nsnull; You sure this doesn't introduce any cycles? Maybe we want to null it out here only if we've got disposition info or something? >@@ -2115,12 +2126,15 @@ nsresult nsExternalAppHandler::CreatePro > mDialog = nsnull; >+ >+ mDispatchable = nsnull; >+ Add a comment explaining that this breaks the cycle? >+NS_IMETHODIMP nsExternalAppHandler::HandleAs(const nsACString& aMIMEType) This needs to enforce the constraints of GetCanHandleAs() and throw if that would return false, I think.... >Index: uriloader/exthandler/nsIExternalHelperAppService.idl >+interface nsIDispatchable : nsISupports Could we please put this in a different file? Especially if we expect to allow embeddors to implement nsIDispatchable? Then again, do we expect people to either call nsIExternalHelperAppService directly or to implement it? If not, perhaps none of these need be public apis? I suppose that's for another bug, huh? :) >+ * In no case will this re-enter the original content handler. This can only be guaranteed if the original content handler is the helper app service, no? I think this should be clarified. >+ * *When this function returns successfully, the current handler WILL NOT >+ * get an onStopRequest call!* Maybe it should? Would that actually break anything in this case? >+ * THIS MUST NOT BE CALLED FROM doContent! This is an internal implementation notes for nsExternalHelperAppService, no? I don't see how it would apply in general... Again, do we expect embeddors to implement nsIExternalHelperAppService? >+ * This method may be called event after onStopRequest has been called, "even", not "event". Which onStopRequest? That's non-obvious from looking at this interface. >+ * in which case the new listener will receive an onStopRequest call before >+ * this method returns. Will or must? That is, is this documentation for implementors of nsIDispatchable, or for coders in nsExternalHelperAppService? The latter reaslly does not belong here... >+ * @param aRequest >+ * The request to dispatch as. Must be the same as passed to doContent. >+ * XXX this sucks. I rather agree.... I'm not sure what the best way to fix this is, conceptually. Perhaps some verbiage indicating the overall interaction of nsIExternalHelperAppService and nsIDispatchable is in order? >+ * No content handler for the registered type was registered; or the >+ * current handler is the handler for the requested type. Do we ever enforce the latter condition? I don't believe we do, and don't see a good way to do it without assuming that the current handler is always the externalhelperappservice. >+ void handleAs(in ACString aMIMEType); This should document that it throws anytime canHandleAs is false or something like that. At the very least, canHandleAs needs to be mentioned here.
Attachment #165908 - Flags: review?(bzbarsky) → review-
(In reply to comment #121) > This wants to NS_PRECONDITION aData and NS_PRECONDITION aRequest, right? fine with me to make aRequest a precondition. aData is allowed to be null though (see the interface docs). > Also, why is it ok to have an aRequest here that's not a channel? When would > that happen, exactly? URILoader in general only handles channels, and we > really do want a channel here to be able to do SetContentType... hm... yeah, that makes sense I guess. > >+ // Save type and stream listener > > "save old type and stream listener in case we fail to redispatch", right? indeed. will make that change. > >+ rv = aData->Available(&count); > >+ // XXX what if that failed? > > We cancel aRequest with rv? That would make the most sense... ok. I guess Cancel will always succeed ;) (it better...) > Hmm... I guess this is an OK context to pass, since there's really no better > one in sight, and we _did_ open this channel ourselves with a null context, > huh? we always pass a null context currently... > Could you write a comment to that effect? sure > I think this would be clearer written as: ok > I'm not so enamored of that change, for the same reasons as apply to the first > comment on this patch... I think I had a good reason for that change. wish I remembered it... > >+NS_IMETHODIMP nsExternalAppHandler::GetCanHandleAs(PRBool* aCanHandleAs) > > This would be better named GetCanCallHandleAs, I think... hmm... ok... I'd prefer my name, but sure. > You sure this doesn't introduce any cycles? Maybe we want to null it out here > only if we've got disposition info or something? Ah... I can do that. my thinking was that the only reference was through necko -> streamlistener (documentopeninfo) -> exthandler. > Add a comment explaining that this breaks the cycle? ok... > This needs to enforce the constraints of GetCanHandleAs() and throw if that > would return false, I think.... oh yeah, good point. > Could we please put this in a different file? Especially if we expect to allow > embeddors to implement nsIDispatchable? I dunno, do we? ;) sure, fine with me. in uriloader/base or exthandler? I guess base is better (I envision possibly passing this to nsIURIContentListener objects as well, sometime in the future) > Then again, do we expect people to either call nsIExternalHelperAppService > directly or to implement it? If not, perhaps none of these need be public > apis? I suppose that's for another bug, huh? :) implement it? heh. that's a really good question. personally, I don't expect anybody to implement it ;) > >+ * In no case will this re-enter the original content handler. > > This can only be guaranteed if the original content handler is the helper app > service, no? I think this should be clarified. that's the only object currently which gets an nsIDispatchable? the code would have to be expanded if we ever pass it to other handlers, sure. I am not sure that I want to give up this precondition, it seems important to let the current handler rely on this. > >+ * *When this function returns successfully, the current handler WILL NOT > >+ * get an onStopRequest call!* > > Maybe it should? Would that actually break anything in this case? I'd have to check. it probably should get onStopRequest... maybe with a special status code? (NS_BINDING_RETARGETED?) I suspect onstopr currently doesn't deal with that very well. > >+ * THIS MUST NOT BE CALLED FROM doContent! > > This is an internal implementation notes for nsExternalHelperAppService, no? I > don't see how it would apply in general... Again, do we expect embeddors to > implement nsIExternalHelperAppService? I don't see how that follows... if doContent does call it, we re-enter uriloader while it's not done with DoContent yet. that seems scary. it would also mean that the new target listener gets two onstartrequest calls (one from uriloader's onstartrequest, to which dispatchcontent returns, to which docontent returns; one from ReDispatch). so this does seem like an nsIDispatchable issue. I can rephrase it as "Must be called in or after onStartRequest", if you prefer that. > >+ * This method may be called event after onStopRequest has been called, > > "even", not "event". Which onStopRequest? That's non-obvious from looking at > this interface. well, the current handler's... I'll mention that. > >+ * in which case the new listener will receive an onStopRequest call before > >+ * this method returns. > > Will or must? That is, is this documentation for implementors of > nsIDispatchable, or for coders in nsExternalHelperAppService? The latter > reaslly does not belong here... well, both. interface documentation can be read from both sides :-) (http://weblogs.asp.net/oldnewthing/archive/2003/12/26/45979.aspx may be an interesting read) > >+ * @param aRequest > >+ * The request to dispatch as. Must be the same as passed to doContent. > >+ * XXX this sucks. > > I rather agree.... I'm not sure what the best way to fix this is, > conceptually. Perhaps some verbiage indicating the overall interaction of > nsIExternalHelperAppService and nsIDispatchable is in order? the real solution may involve storing the request in the DocOpenInfo, but that increases the risk of cycles... > Do we ever enforce the latter condition? I don't believe we do, and don't see > a good way to do it without assuming that the current handler is always the > externalhelperappservice. hmm, guess we never store the uricontentlistener we chose? if we do, DispatchContent could just compare the new one to the current one and fail if they are equal (after CanHandleContent/IsPreferred returned true) > This should document that it throws anytime canHandleAs is false or something > like that. At the very least, canHandleAs needs to be mentioned here. will do
(In reply to comment #122) > fine with me to make aRequest a precondition. aData is allowed to be null though > (see the interface docs). Why, though? What's the use case for a null aData? > > Could we please put this in a different file? Especially if we expect to allow > > embeddors to implement nsIDispatchable? > I dunno, do we? ;) sure, fine with me. in uriloader/base or exthandler? I guess > base is better (I envision possibly passing this to nsIURIContentListener > objects as well, sometime in the future) Ah, to nsIURIContentListener2? That would make sense.... If we do plan to just keep this an exthandler-specific hack, it may be better to just expose that interface on aContext (basically have the object implementing the nsIDispatchable interface be the context, and have it forward to the original context as needed). Then the interface could be in a .h file altogether or something, with all documentation in that file. > that's the only object currently which gets an nsIDispatchable? the code would > have to be expanded if we ever pass it to other handlers, sure. I am not sure > that I want to give up this precondition, it seems important to let the current > handler rely on this. It's a good precondition, but again only one that makes sense if we plan to have multiple handlers that get an nsIDispatchable. If we do, then a lot of these comments make more sense... > > Maybe it should? Would that actually break anything in this case? > I'd have to check. it probably should get onStopRequest... maybe with a special > status code? (NS_BINDING_RETARGETED?) I suspect onstopr currently doesn't deal > with that very well. Special status code and dealing sounds good to me. > I don't see how that follows... if doContent does call it, we re-enter uriloader > while it's not done with DoContent yet. that seems scary. Oh, I agree that it's bad..... > I can rephrase it as "Must be called in or after onStartRequest", if you prefer that. I think that's reasonable. Put an assert in the URILoader code to enforce this, maybe (with a debug-only boolean member set across the DoContent call or something)? > hmm, guess we never store the uricontentlistener we chose? if we do, > DispatchContent could just compare the new one to the current one and fail if > they are equal (after CanHandleContent/IsPreferred returned true) It's almost worse, actually. We want to prevent oscillatory bouncing between two handlers that both want to fob the load off as the type the other one handles... So extending this to allowing all handlers to redispatch would have to be done pretty carefully.
(In reply to comment #123) > Why, though? What's the use case for a null aData? Well, when the handler has no data... f.ex. when wanting to redispatch in onStartRequest... (do we expect embeddors to implement nsIExternalHelperAppService?) > If we do plan to just keep this an exthandler-specific hack, it may be better to just expose > that interface on aContext (basically have the object implementing the nsIDispatchable > interface be the context, and have it forward to the original context as needed). Then the > interface could be in a .h file altogether or something, with all documentation in that file. Hm, yeah, that's also possible. Maybe that's better for now. > It's a good precondition, but again only one that makes sense if we plan to have multiple > handlers that get an nsIDispatchable. If we do, then a lot of these comments make more > sense... This is the question... I certainly considered that case; but is it something we really want to do? If we want to ever replace nsIExternalHelperAppService::doContent with nsIURIContentListener2::doContent (not saying that we want that; just a random thought), then it does need to have some way to get at the nsIDispatchable. > It's almost worse, actually. We want to prevent oscillatory bouncing between two > handlers that both want to fob the load off as the type the other one handles... So > extending this to allowing all handlers to redispatch would have to be done pretty > carefully. ah, hmm... to prevent that, we'd need a stack of handlers (or mime types) and ensure the new type is not in the list... So I'll probably just use your suggestion of making nsIDispatchable available off aContext. putting it in a .h would mean it can't be used from a JS-implemented exthandler; do we want to support that?
> (do we expect embeddors to implement nsIExternalHelperAppService?) I'm tempted to say "no". We have hooks already to modify behavior; changing it altogether would have too many security implications to be worth supporting, I think. We should just clearly document that this is an interface exposed by gecko and move towards freezing it, I think.... (not in the current state, though). > If we want to ever replace nsIExternalHelperAppService::doContent with > nsIURIContentListener2::doContent I think this is a good goal, and when we do this we should revisit nsIDispatchable and its implementation with that expanded role in mind...
So, contrary to the above comments, I do not really want to expose this interface on aContext... currently that's just the docshell, but if it should expose reDispatch, I need to extend that context, probably wrap it somehow. that doesn't seem worth the code to me. On the other hand, adding it to docshell's list of interfaces seems wrong - getting this from a docshell is, I think, not something we want to support.
Attached patch backend patch, v3 (obsolete) — — Splinter Review
Attachment #165908 - Attachment is obsolete: true
Attachment #176645 - Flags: review?(bzbarsky)
Status: NEW → ASSIGNED
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
Comment on attachment 176645 [details] [diff] [review] backend patch, v3 >Index: base/nsURILoader.cpp > +nsresult nsDocumentOpenInfo::DispatchContent(nsIChannel *aChannel, >+ aChannel->SetLoadFlags(loadFlags | nsIChannel::LOAD_RETARGETED_DOCUMENT_URI > | nsIChannel::LOAD_TARGETED); Fix indent of second line here? >Index: exthandler/nsIDispatchable.idl >+ * When this method is successful, the current handler's onStopRequest method >+ * will be called with a status of NS_BINDING_REDIRECTED. I don't actually see us doing this anywhere. Did I miss something? Should we be calling OnStopRequest on oldListener when we reDispatch? r+bzbarsky with these issues addressed.
Attachment #176645 - Flags: review?(bzbarsky) → review+
Attached patch backend patch, v4 (obsolete) — — Splinter Review
transferring r=bz this includes the following change for onStopRequest/NS_BINDING_REDIRECTED: (the if for the else is if (!oldListener)) --- base/nsURILoader.cpp 8 Mar 2005 00:21:40 -0000 +++ base/nsURILoader.cpp 9 Mar 2005 21:22:09 -0000 @@ -445,7 +445,11 @@ status = rv; m_targetStreamListener->OnStopRequest(aChannel, nsnull, status); + } else { + // Otherwise, send the final onStopRequest to the old listener + oldListener->OnStopRequest(aChannel, nsnull, NS_BINDING_REDIRECTED); } + return NS_OK; }
Attachment #176645 - Attachment is obsolete: true
Attachment #176937 - Flags: superreview?(darin)
Attachment #176937 - Flags: review+
Comment on attachment 176937 [details] [diff] [review] backend patch, v4 >Index: exthandler/nsExternalHelperAppService.cpp >+NS_IMETHODIMP nsExternalAppHandler::GetCanCallHandleAs(PRBool* aCanHandleAs) >+{ >+ *aCanHandleAs = mDispatchable != nsnull && mApplyingDecoding; >+ return NS_OK; >+} please add a comment explaining why mApplyingDecoding modifies the value of this attribute. also, it might read a little better as: *aCanHandleAs = mDispatchable && mApplyingDecoding; > NS_IMETHODIMP nsExternalAppHandler::OnStopRequest(nsIRequest *request, nsISupports *aCtxt, > nsresult aStatus) > { >+ if (aStatus == NS_BINDING_REDIRECTED) >+ return NS_OK; NS_BINDING_REDIRECTED is normally not seen by a nsIStreamListener unless someone refused to allow a HTTP redirect through. This status code is seen by a loadgroup observer, however. Do you maybe mean NS_BINDING_RETARGETED? At the very least this deserves a comment to explain what's going on. Also, I don't think we should overload the meaning of NS_BINDING_REDIRECTED. >+NS_IMETHODIMP nsExternalAppHandler::HandleAs(const nsACString& aMIMEType) >+{ >+ // Ensure that this is allowed >+ PRBool canHandleAs; >+ nsresult rv = GetCanCallHandleAs(&canHandleAs); >+ if (NS_FAILED(rv) || !canHandleAs) >+ return NS_ERROR_UNEXPECTED; So, it is okay to call HandleAs without checking GetCanCallHandleAs? I'm asking it because it seems to be the case that I could write code that doesn't check but rather handles the NS_ERROR_UNEXPECTED error. >+ >+ NS_PRECONDITION(!aMIMEType.IsEmpty() && IsASCII(aMIMEType), >+ "Invalid MIME Type argument"); >+ >+ nsCOMPtr<nsIChannel> channel(do_QueryInterface(mRequest)); >+ if (!channel) >+ return NS_ERROR_NOT_AVAILABLE; should this perhaps be checked in canCallHandleAs? >Index: exthandler/nsIDispatchable.idl >+/** >+ * This interface allows re-dispatching a request to a different content >+ * handler. It is useful to allow a user to choose to view a file as a >+ * different type than it really is. >+ */ >+[scriptable, uuid(69314C16-EDAD-4c9d-931C-DE2D438F9CF7)] >+interface nsIDispatchable : nsISupports I'm not crazy about the name of this interface. The name suggests that this would have a method named dispatch or something. How about coming up with a name that is more specific. nsIDocumentOpenInfo is not great of course. What it seems like to me is that you are retargeting the channel. Maybe that is because I am necko-centric, but nsIChannel does have a LOAD_TARGETED flag that corresponds to when a channel has a final consumer. Part of the problem here I think is that you are forced into exposing this as a callback interface because of nsIExternalHelperAppService:: DoContent. But, in reality, no one but nsURILoader.cpp should ever care to pass a nsIDispatchable to that DoContent. It seems to me that consumers outside this module will instead focus on the HandleAs API. So, it seems to me that we might be unnecessarily introducing a XPCOM interface for communication between nsDocumentOpenInfo and nsExternalAppHandler. Why not deCOMtaminate this relationship? I'm also not fond of canCallHandleAs. That just doesn't read well. allowsHandleAs, permitsHandleAs, or supportsHandleAs might be better.
Attachment #176937 - Flags: superreview?(darin) → superreview-
*** Bug 291120 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > Doesn't it make sense to display text/<unknown> as text/plain? The files on that > page are all served as text/x-csrc. I had to save a bunch to disk and use a > console to view them. I'm just quoting this because it's basically what I was going to say. Google is serving up files with text/rfc822-headers in error mails, and I would like to have read that in the browser.
Errors that this will solve are very rare and non for ordinary users either, long fixing is proof ;-). There're 2 issues: transfer encoding and MIME type of content. So my proposal for GUI is here, click GUI but not use code (-: <http://flower.upol.cz/~olecom/bugs/m-57342/nsHelperAppDlg.xul> Note that i propose to use list of internal MIME handlers. Also if link will be downloaded, navigators's tab or window must not be opened at all. Menu from that link maybe only useful if there's info about errors: <https://bugzilla.mozilla.org/show_bug.cgi?id=11521#c25>
that UI seems a bit complex...
I actually think it's a pretty nice UI, the only problem is options 4 and 5 being a bit confusing. I think it could say "View in Firefox as v|a web page|" |plain text|" That would be nice and easy
(In reply to comment #80) > But there *does* need to be an escape route, because the failure mode results in > far more effort than is reasonable to work around, currently. It *should* just > work transparently, yes, but it sometimes doesn't and in those cases it really > doesn't need to fail that badly. John is absolutely right. We should be mortified that this bug is still open after 5 years. The user needs to be able to cope with misconfigured servers by <a href="http://forcecontenttype.mozdev.org/screenshots.html">changing the content type</a>. The last 9 months of comments on this bug are an impenetrable morass of patch discussion. Can someone please summarize the current state of affairs?
> Can someone please summarize the current state of affairs? someone needs to update the patch per comment 130; something which I haven't yet found the time for.
(In reply to comment #137) > someone needs to update the patch per comment 130; something which I haven't yet > found the time for. Thanks for the info. Can anyone expand on that a bit? From a user's perspective, what will this patch accomplish?
> From a user's perspective, what will this patch accomplish? nothing. someone will also have to write UI code.
(In reply to comment #139) > > From a user's perspective, what will this patch accomplish? > > nothing. someone will also have to write UI code. Can that be done in javascript? I'm willing to work on it, but I don't know any internal APIs.
(In reply to comment #136) > (In reply to comment #80) > > But there *does* need to be an escape route, because the failure mode results in > > far more effort than is reasonable to work around, currently. It *should* just > > work transparently, yes, but it sometimes doesn't and in those cases it really > > doesn't need to fail that badly. > > John is absolutely right. We should be mortified that this bug is still open > after 5 years. The user needs to be able to cope with misconfigured servers by > <a href="http://forcecontenttype.mozdev.org/screenshots.html">changing the > content type</a>. > > The last 9 months of comments on this bug are an impenetrable morass of patch > discussion. Can someone please summarize the current state of affairs? I will _not_ install jslib on my box for it. JS in mozilla has many bugs with linux i want to fix. IMHO jslib is another _easy lame way_ ! External extensions maybe used only if mozilla can't handle it by itself, so it will no forest of menus and options. GUI ? I may do GUI in way i proposed, and it is useful but not complex.
can that discussion be moved elsewhere, please...
(In reply to comment #134) > that UI seems a bit complex... For firefox user yes ;-) Issue with options 4 and 5 is that they propose conversion prior to problems. My new proposal is to move dialog with this options in "View/Show As" menu, while adding only "new as text/plain" option in open dialog, thus solving problems like this: - try to view any image from <http://www.elf.org/pnglets/> - <http://flower.upol.cz/~olecom/bugs/m-57342/eindex>
No longer blocks: majorbugs
SUBJECT: Another user situation description. AGENT: Mozilla 1.7.8 Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 1) A "proper behavior" example. This seems to be a problem not only of Mozilla but also of malformed server configs. I've tryied opening directly C/C++ source code files by typing the URL on the address bar, and the file is rendered (as expected) as text/plain. By right-clicking the rendered text window and selecting Page Info, it reports it is MIME type "text/plain" (not "text/x-csrc" or similar? weird...), with "Quirks mode" rendering mode. For the time-being I have an example at http://fisica.fc.ul.pt/~jbatista/tstamp.c 2) A "improper behavior" example. On other examples I've seen (regretably, it's behind a firewall so it's no point [and I've tried!] putting the URL here, sorry), even though I've explicitly edited the HTML anchor to assign type="text/x-csrc" and even type="text/plain", this is what happens. The browser complains it DOES NOT recognize the MIME type text/x-csrc (i.e., it correclty identifies the MIME type...) and asks how the file should be opened. The specific link points to a *.c file linked to by a Tikiwiki page ( http://www.tikiwiki.org/ ), this page being generated by a PHP script. Now, IMHO it is likely that the Tikiwiki somehow screws up the Content Type string (if indeed one is sent). So, IMHO it seems that if some server-side application (Tikiwiki most certainly, some Apache configurations likely) attempts to interpret the file's contents and send the Content Type string. However, Mozilla does not know what to do with text/x-csrc MIMEs. On the other hand, it appears in example 1) that there was no inclusion of a "Content Type" string in the data stream, and the stream is identified by Mozilla as text (hence the text/plain). But I'm just theorizing since I haven't looked into the Mozilla code... I suppose there are ways to have a look at the data stream's content, right? How is it done (pardon the newbie question)? If someone tells me I'm likely to try it and post here the results, if there's interest on them. :-)
João, the MIME-type is set by the webserver, not the browser. So it's the webserver that chooses text/plain for a *.c file. Apache uses the file-extension for it, it doesn't look in the contents. Note that Gecko gives priority to the HTTP-header 'Content-Type', not to a META-tag. So your webpage can't override it inside the page (example 2), unless there's a way to specify the header (user the header-function in PHP for example, but that has to be done before the first line is printed).
(In reply to comment #144) > right-clicking the rendered text window and selecting Page Info, it reports it > is MIME type "text/plain" (not "text/x-csrc" or similar? weird...), That is because the server sending the file said it was text/plain. > I suppose there are ways to have a look at the data stream's content, right? > How is it done (pardon the newbie question)? For this example the interesting question is simply "what type is the server labeling this file as?" You can check like this: $ telnet fisica.fc.ul.pt 80 HEAD http://fisica.fc.ul.pt/~jbatista/tstamp.c HTTP/1.1 Host: fisica.fc.ul.pt HTTP/1.1 200 OK ... Content-Type: text/plain; charset=ISO-8859-1
(In reply to comment #146) > (In reply to comment #144) > > I suppose there are ways to have a look at the data stream's content, right? > > How is it done (pardon the newbie question)? > > For this example the interesting question is simply "what type is the server > labeling this file as?" You can check like this: > > $ telnet fisica.fc.ul.pt 80 > HEAD http://fisica.fc.ul.pt/~jbatista/tstamp.c HTTP/1.1 > Host: fisica.fc.ul.pt > > HTTP/1.1 200 OK > ... > Content-Type: text/plain; charset=ISO-8859-1 Hi Chapman, FYI my results are below. As you can see in both cases, for which I obtain different results, the Content-Type is the same, namely text/x-csrc. It's even more confusing because the PHP generated the (apparently) correct HTML: I got "<a href="temp/4587d12e416c8ab1e8ba9b11d9d47f7c/4587d12e416c8ab1e8ba9b11d9d47f7c.C" target="_blank" type="text/x-c++src"><p align=center>Click here to view this ROOT C++ script's source code</p></a>" as I would expect, but the problem persists. HOWEVER, if I change the file's name to have an extension .txt instead of .C, then it opens with no problem... :-o For the first ("good") link: --------------8<--------------8<--------------8<--------------8<-------------- $ telnet fisica 80 Trying 194.117.43.10... Connected to fisica.fc.ul.pt. Escape character is '^]'. HEAD /tikiwiki/temp/4587d12e416c8ab1e8ba9b11d9d47f7c/4587d12e416c8ab1e8ba9b11d9d47f7c.C HTTP/0.9 HTTP/1.1 200 OK Date: Thu, 08 Sep 2005 16:28:43 GMT Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d Last-Modified: Thu, 08 Sep 2005 07:51:20 GMT ETag: "7c008-22-431fed78" Accept-Ranges: bytes Content-Length: 34 Connection: close Content-Type: text/x-csrc Connection closed by foreign host. --------------8<--------------8<--------------8<--------------8<-------------- For the second ("bad") link: --------------8<--------------8<--------------8<--------------8<-------------- $ telnet fisica 80 Trying 194.117.43.10... Connected to fisica.fc.ul.pt. Escape character is '^]'. HEAD /~jbatista/tstamp.c HTTP/0.9 HTTP/1.1 200 OK Date: Thu, 08 Sep 2005 16:29:03 GMT Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d Last-Modified: Thu, 08 Sep 2005 07:36:19 GMT ETag: "1ec007-9f-431fe9f3" Accept-Ranges: bytes Content-Length: 159 Connection: close Content-Type: text/x-csrc Connection closed by foreign host. $ --------------8<--------------8<--------------8<--------------8<--------------
(In reply to comment #147) I'll keep this comment brief as this issue seems to be veering OT for this bug: > For the second ("bad") link: > $ telnet fisica 80 > Trying 194.117.43.10... > HEAD /~jbatista/tstamp.c HTTP/0.9 > > HTTP/1.1 200 OK > Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d > Content-Type: text/x-csrc The curious thing here is that you've queried the same server for the same file I queried in comment #146 and the server gave you a different content type than it gave me. Even more curious, a couple of lines I clipped from comment #146 to keep it brief, but still have in my xterm: Trying 194.117.43.10... ... Server: Apache/2.0.54 (Gentoo/Linux) PHP/4.3.11 mod_ssl/2.0.54 OpenSSL/0.9.7e So, we've both connected to the same IP address, but got distinctly different servers on different machines. I would guess fisica is doing some load sharing among different machines behind the same outside IP, and they are configured differently. Getting different content types for the same file on different occasions could cause some puzzling symptoms. But probably beyond the scope of this bug (except as another illustration of why it would be really useful to be able to override the declared content type when needed).
(In reply to comment #148) > Getting different content types for the same file on different > occasions could cause some puzzling symptoms. But probably beyond the scope of > this bug (except as another illustration of why it would be really useful to > be able to override the declared content type when needed). > My feelings exactly. IMHO it would be sensible to allow the user to circumvent badly configured Web servers, by allowing the user to select an appropriate action -- at least on those occasions that Mozilla finds out it does not know what to do with a given MIME type. On this note, I would vote for the UI look on comment #62 , perhaps clarifying on those entries with the MIME type in parethesis, eg: (o) View as [Text v] +------------------+ | Text (plain/text)| | Image (image/*) | | HTML (text/html) | | XML (text/xml) | | Other... | +------------------+ I'm hesitant to suggest that selected MIME types with "Other..." would show up after being selected. E.g., if the user chose to open an URL using a MIME type application/x-pdf, then the appropriate entry would also show up on subsequent calls of the drop-down menu.
(In reply to comment #149) > (o) View as [Text v] > +------------------+ > | Text (plain/text)| > | Image (image/*) | > | HTML (text/html) | > | XML (text/xml) | > | Other... | > +------------------+ > > I'm hesitant to suggest that selected MIME types with "Other..." > would show up after being selected. E.g., if the user chose to > open an URL using a MIME type application/x-pdf, then the > appropriate entry would also show up on subsequent calls of the > drop-down menu. I'm hesitant to think we should go this far. A reasonable start would be to list the formats that the browser has built in. Listing plugins here might clutter it up, especially as more are added, so it might make sense to separate them off somehow. And if we put the plugins in a separate list, how sensible would it be to have all installed plugins in one list?
I agree. I think we should start with the basic menu, without "Other...", and go from there.
*** Bug 308632 has been marked as a duplicate of this bug. ***
*** Bug 313296 has been marked as a duplicate of this bug. ***
Apologies, I can't figure out the status of this bug from the last few posts on it. I like the sound of comment #102. This feature seems to be being held up by implementation problems for on-the-spot user decision of what to do. Comment #102 suggests an approach whereby a user can specify in advance what MIME types he wants to view inline always. Why can't *THAT* be implemented first (and seperately), and then when *this* finally gets done, there can be a tick box "always do this", which is the equivalent of the configuration gizmo? In other words, why isn't there a seperate bug for what I outline above so that there is actually a way to handle the problem, for now, and stop people whining on this bug?
Why don't we just implement "View as text" first, then worry about other formats later?
(In reply to comment #155) > Why don't we just implement "View as text" first, then worry about other > formats later? ? that doesn't make any difference in terms of development effort.
*** Bug 319974 has been marked as a duplicate of this bug. ***
I've found that creating a MIME handler of: mozilla -remote 'openFile(%s)' does pretty much exactly what I want. Surely it can't be that hard for someone who knows the codebase to implement that internally?
Security consideration: Gmail appears to use content-disposition: attachment to prevent HTML attachments from being used in XSS attacks. We should avoid breaking that if we add this feature.
(In reply to comment #159) > Security consideration: Gmail appears to use content-disposition: attachment to > prevent HTML attachments from being used in XSS attacks. We should avoid > breaking that if we add this feature. Concerning content-disposition, see bug 185618. But not taking content-disposition into account is the right way, as it is a non-standard header, which should thus be ignored (though a different behavior could also be chosen as an option). If Gmail is based on such a non-standard feature for security consideration, then it is highly broken.
Content-disposition is described in http://www.faqs.org/rfcs/rfc2183. It is also mentioned in the "Security considerations" section of the HTTP spec (http://www.faqs.org/rfcs/rfc2616), although it's not clear what security considerations it's talking about. Btw, I'm not sure I agree with the way you equate "non-standard" with "wrong".
(In reply to comment #161) > Content-disposition is described in http://www.faqs.org/rfcs/rfc2183. It is > also mentioned in the "Security considerations" section of the HTTP spec > (http://www.faqs.org/rfcs/rfc2616), although it's not clear what security > considerations it's talking about. The security considerations concern the directory path information. I've mentioned it in bug 185618 comment 45. Concerning this bug 57342, whose goal is to be able to view the contents for unsupported media types, there's nothing to save, therefore no security problems. > Btw, I'm not sure I agree with the way you equate "non-standard" with "wrong". When a non-standard feature modifies the normal behavior documented in standards (in a non-optional way), this is a bug.
> Btw, I'm not sure I agree with the way you equate "non-standard" with "wrong". I'm not sure I agree with the hidden implication that something is "right" just because Gmail does it.
For those who can't wait for this to be implemented, I've made an extension to open documents in browser. It is a kind of hack, but it can make life easier for some people: http://www.spasche.net/mozilla/
The extension is great. Just what I was looking for !! Thanks !
Great extension. Do you think you could add application/pdf to its known MIME-types?
(In reply to comment #166) > Great extension. Do you think you could add application/pdf to its known > MIME-types? That could be added to the feature list. Please use the mozillazine forum (http://forums.mozillazine.org/viewtopic.php?t=430010) for such requests, as this is outside of the topic of this bug. Thanks
I have been using the extension of Sylvain (http://www.spasche.net/mozilla/) for a while now, and indeed, it is great. However, this is basic browser functionality and should NOT be a custom extension. All it does is make the browser behave as it always should have, and as Opera has done since at least version 3.5 (!). Please incorporate this extension or it's functionality into the standard browser code!
(In reply to comment #168) > Please incorporate this extension or it's functionality into the standard > browser code! I agree. I think this is important, not just for Firefox users, but for the web in general. Indeed an extension is not sufficient, otherwise many users won't be able to see text/* files by default, meaning that web authors will give an incorrect media type to source files, just to be compatible with Firefox. Could this block the next Firefox version?
(In reply to comment #169) > Could this block the next Firefox version? Maybe if there's an unrejected patch against the trunk... either based on the extension or the previous patch. Otherwise, not really. Unfortunately.
Did it ever dawn on you that this is a Gecko bug? A lot of other applications benefit from Gecko too, not just Firefox.
*** Bug 360817 has been marked as a duplicate of this bug. ***
*** Bug 360979 has been marked as a duplicate of this bug. ***
This is an update of the latest patch against trunk. It does not address Darin's comments yet. As one could expect, it did not apply cleanly, so I had to manually merge some stuff. I had not much success with this new patch applied: If I select for instance text/html for the mime to redispatch, I'm getting assertion: ###!!! ASSERTION: nsExpatDriver didn't get an nsIExpatSink: 'Error', file /[...]/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 1180 Then the originating window is staying in loading state (the spinner is running), and if I click on the window, I can see the assertions: WARNING: NS_ENSURE_TRUE(aPresContext->Document()->GetWindow()) failed: file /[...]/mozilla/content/events/src/nsIMEStateManager.cpp, line 174 When stepping inside the nsDocumentOpenInfo::ReDispatch function, I can see that the m_targetStreamListener->OnDataAvailable() call is failing and is in the callstack when the nsIExpatSink assertion is thrown. If you have any hints about this, they are welcome.
Attachment #176937 - Attachment is obsolete: true
The issue comes when nsDocumentOpenInfo::ReDispatch is called after the initial request is finished (OnStopRequest called). In that case, the call to aChannel->SetContentType(aMIMEType) in nsDocumentOpenInfo::ReDispatch does not change the content type, as the channel has no listener any more. Because the content type did not change, the parser thinks it is XML, that's why we saw expat exceptions. I tried to hack nsHttpChannel::SetContentType to force setting the content type, even when it has no listeners. That fixes the expat assertion and the page displays, but the spinner keeps running and there's some assertions appearing: -1610559552[2307150]: WARNING: NS_ENSURE_TRUE(aPresContext->Document()->GetWindow()) failed: file /[...]/mozilla/content/events/src/nsIMEStateManager.cpp, line 174 -1610559552[2307150]: ###!!! ASSERTION: win is null. this happens [often on xlib builds]. see bug #79213: 'Error', file /[...]/mozilla/content/events/src/nsEventStateManager.cpp, line 957 If Redispatch is called while the request is not finished, things seem to be working better (spinner stop running after page is finished). I used the following useful URL for testing: http://www.hixie.ch/tests/evil/page-loading/incremental/001.cgi
Depends on: 369787
Any news on this bug? It's been some time since the last post.
This is a very useful and common-sense option, which I'd like to see fixed inside the browser. I'm annoyed with trying to view text files that have alternative MIME types (e.g. LaTeX) by launching the editor. The "Open in browser" extension doesn't work all the time, and this is something so simple that it should just be a care part of the browser.
We should really find someone to drive this in... I can try to do it, but then I need to find someone else to review the whole thing.
I was a little shocked when I reported bug 463361 to discover it had been around in one form or another since 2000. Why is it that it cannot be as simple logic as "if open url triggers download code && firefox.exe is the application associated, dump as text to screen". Something this simple could also be expanded later to handle some of these other related bugs. "If mime type x == associated to firefox.exe do-> some method else dump as text". Inserting call to extension or internal code set at "some method" This would prevent the infinite loop problem and allow for extendability.
Assigning to myself, the hapless new necko maintainer. This does look like a good bug to finally fix, so it looks like it will be high on my list.
Assignee: cbiesinger → jduell
Now when you read my comments, I want you to take them on board, because I speak for the whole firefox users community. And if you decide to take offence, then thats tough, but I am writing it like I feel it because I am ANGRY AND ANNOYED. Bugs like these should have been resolved a long time ago and I complained about this way back when firefox was still in it's infancy and some stupid sod deleted the bug entry and back then I was as polite as hell and even offered some advice. My complaint is that jpeg files won't just open in firefox, even though they can and are opened in firefox when I tell the stupid dialog box to just open the damned thing in firefox. And yes I have set firefox as the default handler for jpeg files and no the file isn't cymk. I can't believe how lazy you people can be. A bug that has been around for 9 years and not one can fix it. Says a lot for your programming skills eh. Can't you people see how you are just turning people away from firefox. I personally am testing Opera and once I get to grips with it's ins and outs, I will be switching over to that because I am so fed up of all the lousy bugs that have never been fixed in firefox and the way your company is just becoming a smaller version of microcrap. Most of these dammed files can be and eventually are viewed in firefox, so why can't someone just program the damned program to just open them in firefox without having to put us all through the nonsense of the save as dialog box. Personally, i think you lot should be ashamed of yourselves, especially since there are many more bugs that have been around for ages. But, if you bunch of lazy sods want firefox to die, then on your own heads be it. And when I say LAZY I damn well mean lazy. ANd yes I am bloody angry that this and the many other bugs STILL HAVEN'T BEEN RESOLVED.
To comment 183, I think I speak for the "whole firefox users community" when I say "Goodbye, and good riddance." To everyone else, sorry for bugspam, I couldn't resist...
Indeed - if you were so upset you should have taken those nine years to patch it yourself! This is a community of volunteers after all. Thank you to everyone who has contributed to this.
With due respect to commenters 184 and 185: Users are certainly justified in being upset about relatively simple high-visibility bugs like this one not being fixed. Commenter 183 may have gone overboard, but he has been bottling it up for 9 years after all... So, no, it's not "Goodbye and good riddance". Also, Firefox is not now the product of a community of volunteers, but rather mostly of a group of salaried programmers, with much financial backing from Google (if not as much as one would expect given the circumstances). That group can be expected to satisfy certain user needs, such as having this bug resolved. Even Google itself can be expected to have them satisfied. And, finally, why do some people assume everyone can code at all, not to mention get a handle on a huge project like Firefox enough to be able to fix such a bug? A tiny tiny minority of users have the skills and the time to do so. Sorry for the bugspam.
Ill apologize in advance for morebug spam on this. I do definitely think this bug should be fixed, and that it is way overdue. I do not discredit someone who gets **** over being mad at the status either. However I would like to point out that there is a workaround for this bug. 1) copy the link (right-click --> "copy link location") 2) clear the address bar (ctrl-l) 3) type "view-source:" and then paste in the url (ctrl-v) 3) enter However IMHO this is inadequate, and the bug should still be fixed as described.
With regards to Marks comments (Comment #185) I am not a software programmer. I design web sites and if ever I have encountered problems similar to this, I have always taken the time to resolve them, both to the customers satisfaction and because I take pride in my work. If you are a firefox programmer Mark, then you are one of those people who are to blame for the eventual demise of firefox and I hope that one day this realisation will hit you fully and that it may do so in a way which will force you to see how crass and childish your comments are. As mentioned above (Comment #186 From Eyal Rozenberg) Firefox is owned by a huge corporation with so much money that it can afford to fix such annoying problems and the fact that even after complaining about this bug and having my original complaint, first dismissed as stupid (and said to be my fault, because apparently I didn't understand how web browsers work) and secondly when it was deleted with no reasons given for the deletion, simply shows how such huge corporations disrespect their users and prioritise their own aims before those of the people who actually use their products. I would also like to add that I supported firefox from the day I discovered it, this after being an avid fan of IE for many years. Then I started web design, after which I discovered the shortcomings of IE and from that day, through my various web sites and through word of mouth, I have convinced many people to switch to firefox in the belief that here was a web browser being developed by ordinary people for ordinary people. Marks comments above illustrate exactly the kind of attitude which puts users off badly programmed software and this is just an additional reason for my looking to switch over to Opera. Additionally, I dislike the fact that over the years I have seen many good ideas and suggestions for improvements to Firefox dismissed as unecessary, or too time consuming and I do not think that I want to be a part of a project which does not accept new ideas, or innovations as seriously as it should. I still have to use firefox for development purposes and I will admit that I think it has a lot of great functions which are missing from most of the other browsers and that I will miss it and the firefox community. I wish you all the very best for the future and hope that someone who takes pride in their work eventually resolves this problem, but sadly, I do not think that I will be a firefox user long enough to see that day.
QA Contact: chrispetersen → file-handling
Target Milestone: mozilla1.8beta2 → ---
Apologies in advance for more bugspam, but I have some additional points to make: (In reply to comment #183) > Now when you read my comments, I want you to take them on board, because I > speak for the whole firefox users community.... Actually, you don't. > Bugs like these should have been resolved a long time ago ... Why should the bug have been resolved a long time ago? It's not affecting most users, not causing systems to crash, deleting data, etc.? At most it's an annoyance with a workaround (and perhaps a plugin). Indeed, if you read the history of the bug, it wasn't initially clear *how* to fix it. The Add "View as..." option came about after some discussion. And while it seems simple to fix for a non-programmer, web browsers are complex. There are still a couple of bugs that this bug depends on. > My complaint is that jpeg files won't just open in firefox, even though they > can and are opened in firefox when I tell the stupid dialog box to just open > the damned thing in firefox. And yes I have set firefox as the default handler > for jpeg files and no the file isn't cymk. Whoa! That's a different bug altogether. So file a different bug. And give useful details, like what operating system, and links to or attachments of example jpeg files that are problematic. > I can't believe how lazy you people can be. No, just busy with more important things. > A bug that has been around for 9 years and not one can fix it. Says a lot for > your programming skills eh. ... "You catch more flies with honey than vinegar."
> Additionally, I dislike the fact that over the years I have seen many good > ideas and suggestions for improvements to Firefox dismissed as unecessary, or > too time consuming and I do not think that I want to be a part of a project > which does not accept new ideas, or innovations as seriously as it should. Yes, but this is nothing new. This is a general property of the open-source development model which is not going to improve soon. (http://mpt.net.nz/archive/2008/08/01/free-software-usability, see point #3)
Robert Rothenberg, you and small minded people like you, must enjoy picking apart peoples comments as opposed to fixing bugs. When i say I speak for the majority of firefox users, I actually because as mentioned in my previous post I have lots of customers and friends and family to whom I recommended firefox and they too encounter the same problem and the only reason they do not complain is because they are not technically minded, or do not feel confident enough discussing such matters, as do most ordinary firefox users. Bugs like these should have been resolved a long time ago because as mentioned, I reported this very same problem over 7 years ago and again as mentioned in my previous post, it was deleted and another egotistal programmer simply dismissed it and deleted the bug I reported. With regard to this bug not being the same bug, it might not be, but no one else has protested about it and it is a mime type bug which has the same kind of problem as the other file types mentioned here. It is affecting users and whilst it does not crash tthe browser, we users don't want to waste our time clicking on silly dialog boxes because of faulty functionality which LAZY programmers like you cannot be bothered to fix because you want to go watch porn or whatever you call important. I too have done some programming and I know that problems like these arise from bad coding practices which haven't been corrected. BTW this features works fine in every other web browser that I have used and I don't need to click on a single dialog box to view a jpeg file (as opposed to a jpg file). Now if you consider that unimportant then obviously you don't have the intellectual capacity to grasp what I am saying. Using stupid qutoes doesn't alter the fact that this BUG has been around for as long as firefox has been in existence and well, if you cannot be bothered to fix such problems, then obviously you can't be all that good a programmer, so what the hell are you doing being involved in such a project if its beyond your capabilities. People with attitudes like yours should not be involved in projects like these because your incompetance causes mroe problems in the long run and the manifestation of that is a long list of faults which we users have had to endure, but no more thanks to opera. And I think that the 100's of thousands of readers of my web sites will agree with me, especially when I post your comments on my web sites, so they can see exactly how some firefox programmers instead of accepting constructive criticism, cry like a little baby and try to bad mouth their users. One final word. If you cannot tolerate constructive criticims by a firefox user of long standing then I suggest you go back and hide under your mummys apron because all I have done is to express my anger and frustration at a bug which as mentioned I reported long ago and which nothing has as yet been done about.
Again, apologies for the bugspam.... (In reply to comment #191) > Robert Rothenberg, you and small minded people like you, must enjoy picking > apart peoples comments as opposed to fixing bugs. Insulting people who do not agree with you will get you nowhere. > When i say I speak for the majority of firefox users, I actually because as > mentioned in my previous post I have lots of customers and friends and family > to whom I recommended firefox and they too encounter the same problem ... > ... > With regard to this bug not being the same bug, it might not be, but no one > else has protested about it and it is a mime type bug which has the same kind > of problem as the other file types mentioned here.... Again, provide technical details about the bug (URLs, browser versions, operating system versions, etc.), so that it can be diagnosed, rather than ranting about how there is a problem that no one is fixing. It doesn't seem to affect that many users. From your description, it seems to affect YOUR clients, so perhaps it is something YOU are doing: is the webserver returning the appropriate MIME type for the JPEG files? > BTW this features works fine > in every other web browser that I have used and I don't need to click on a > single dialog box to view a jpeg file (as opposed to a jpg file). Now if you > consider that unimportant then obviously you don't have the intellectual > capacity to grasp what I am saying. That could also mean that Firefox is behaving correctly and the other browsers are poorly implemented and ignoring an error. > One final word. If you cannot tolerate constructive criticims ... Your criticisms have not been constructive at all. They have been insults. If you want to be constructive, provide some useful information about the specific problem you are having.
Could the people who should know better please stop saying "Sorry for the bugspam, but . . ." and then spamming everyone? If your sense of indignation at this user is such that you can't stand letting his claims go un-rebutted, try replying by e-mail. (And yes, I'm not practicing what I preach, but several different people have been doing this here so far and probably more will even if I privately e-mail everyone who's done it so far.)
I'd like to take this chance to remind everybody commenting lately of the Bugzilla Etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) that governs this Bugzilla instance. Most of the recent comments in this bug have been in violation of one or more points in the Etiquette, and recent activity has started to generate a lot of complaints. Please do not comment in this bug unless you're discussing how best to fix this bug, attaching a patch to fix it, or are doing sometime actually useful rather than making pointless bugspam that doesn't help anything. This is your *only* warning. Any future violations of the Bugzilla Etiquette will result in the disabling of the violating Bugzilla accounts. Bugzilla is not a forum for such comments. If you wish to rant, the newsgroups are the appropriate place for such comments, not Bugzilla. Again, this is your *last* and *only* warning. Thank you for your time.
Basic designs are not solid, yet. The problem is that users can close the original window (or tab) before choosing some option in external-app dialog. This could causes multiple bad results. It's okay to open it in a new tab, please think about such a link: <a href="unknown_mime.txt" target="my_target"> See the target. </a> In this case, user may close "my_target" window before loading any content into it. Gecko should force to open a new window nonetheless, on user chosing "Handle inside Gecko"? In summary, I think external-app window should be a modal dialog. Or it needs a way to protect original DOM window, such as overlapping bar or something like that.
Attached patch PoC modal dialog — — Splinter Review
Proof of concept. You can see how simple the patch will be, if external-app dialog were modal. And probably less buggy. I don't think simpleness beats usability, as I get annoyed even with HTTP password prompt. But, in my opinion, keeping it modeless is difficult, for very the same reason why we don't have modeless password prompt.
Jason Duell, this has been assigned to you for almost six months. What is it about this bug? Why does it never get solved? I'm not asking to bitch, I just don't understand why it takes nine years to display files. The techncial solution has existed for three years as an addon: https://addons.mozilla.org/en-US/firefox/addon/8207 While this bug is clearly not a data loss or security issue. I'm sure there are a few bugs out there that deserve higher priority. But as a user of firefox, my impression of 95% of the things that do get worked is that they should not have been chosen over this one. The addon above has demonstrated a viable technical solution, and has existed for three years. How about implementing it as is? If there are criticisms of it, how about implementing it anyway and dealing with improving it later? It's fascinating how certain bugs like this one can have some kind of "group think" where a zombie like mental paralysis seems to descend and prevent common sense from prevailing. I'm not interested in denials, rebuttals, excuses, explanations. I just want to open files in my browser without having to install the "don't suck" addon.
I'm curious how the extension avoids the security issues that a naive implementation would have.
Depends on: 504441
I filed bug 504441 for the security parts, which will probably want to be a separate patch anyway.
(In reply to comment #199) > I'm curious how the extension avoids the security issues that a naive > implementation would have. Just to clarify, the extension doesn't protect users from malicious scripts when viewing documents as html. I'll see if I can do something like bug 504441 inside the extension, or maybe show a warning when viewing a mime type that runs scripts. By the way, I noticed that Opera 10 doesn't protect the user from these kinds of security issues.
I am not sure if this is still an issue but initially it seemed the technical issues involved were that there was no way to get back to the browser from the helper application. How about a different approach? I propose no UI but rather only have an option in about:config. I am not sure of the correct section but something like: browser.display_alltext_as_plain default would be FALSE and exhibit current behavior but if changed to TRUE the browser just treats it as text/plain and never takes the external handler path.
See Also: → https://launchpad.net/bugs/25830
(In reply to comment #202) > issues involved were that there was no way to get back to the browser from the > helper application. How about a different approach? I propose no UI but Presumably the bit of code *within* firefox that deals with external helpers, since before the user has dismissed the unknown type dialog, the actual external helper can't possibly exist. > rather only have an option in about:config. > I am not sure of the correct section but something like: > browser.display_alltext_as_plain 1) Even for types that look like plain text, I might not want this all the time. Sometimes I really want to view source code with an oddly specific mimetype in firefox with minimal fuss. Sometimes I happen to know the server is going to spew 50MB of ASCII machine logs out and really want it to go directly to the helper rather than wedge the layout engine for a minute. 2) This isn't a text-only issue. Only today I had firefox pop the dialog for a PNG image that was presumably incorrectly tagged. As I've pointed out before, the truly crazy thing is you can select firefox as the external helper and it will dutifully write it out to disk, launch firefox externally on the file, presumably it then uses dbus/DDE/some other equivalent method to pass the file back to the original firefox instance which then displays it just fine. However you've lost the original HTTP session context there: refreshing won't reload and certain other things look/behave differently. The final solution (ignoring any necessity of a dialog for user choice in the matter) should end up behaving exactly as if firefox had known what to do from the beginning.
(In reply to comment #203) > 1) Even for types that look like plain text, I might not want this all the > time. Sometimes I really want to view source code with an oddly specific > mimetype in firefox with minimal fuss. Sometimes I happen to know the server is > going to spew 50MB of ASCII machine logs out and really want it to go directly > to the helper rather than wedge the layout engine for a minute. This can also happen with text declared as text/plain, or even HTML.
the extension „open in browser“ doesn’t work on local files (offering only „view source“) the solution should work on those, too.
(In reply to comment #201) > (In reply to comment #199) > > I'm curious how the extension avoids the security issues that a naive > > implementation would have. > > Just to clarify, the extension doesn't protect users from malicious scripts > when viewing documents as html. I'll see if I can do something like bug > 504441 inside the extension, or maybe show a warning when viewing a mime > type that runs scripts. > > By the way, I noticed that Opera 10 doesn't protect the user from these > kinds of security issues. Nor does Firefox, on any content that is HTML from the start or relabeled as such by the extension.
I suggested a more general solution in bug 185618 comment 61 (about adding an option to render content in Firefox whenever "Save As" comes up immediately). I suggest using an error/info page for content of a type for which there is no handler or for content for which the handler fails, so anytime Save As comes up there is some content behind it. In the case of an unknown type, the error/info page would appear as a placeholder, which would prevent unknown types from cutting off user activity, and make room for a separate "Reinterpret Content" sheet with which the user could override the provided content-type to one which Firefox can render.
I need "open in browser" working ! , I hope this is not another stupid security reason
i am using Waterfox 24.0 (64 bit build version of firefox) on Windows 7 x86 64 bits. when visiting this page: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/1_10_00_23/index_FDS.html (might require a free account to view or download) and downloading the windows version (*.exe) of the file set then i can select any option for opening or saving including the "remember my decision" option. but when going for the linux version i only get offered two options: open with an application (default here is VLC) or download but the "remember" button is grayed out. for my impression the browser should be able to remember decisions for explicitly html/mime tagged file formats as already realized. but for for non-tagged or "wildcard"-tagged files and it shall be check for the file name extension (or absence of such an extension - this happens more often than you would think) and decide based upon that extension. so the browser needs not only a mime type default action configuration database/listing but an extension based handling if mime type is not that useable. maybe even the user can pass down certain mime types to the extension based treatment. thus the mime type layer should see a new option: "handle by file extension". @Sergio - thats a nice proposal in that area. i can support that. its all about options. BTW i think the dialog does not mention the mime type so i am a bit lost in diagnostics for that my faulty cases using purely the browser. the dialog should mention the mime-type he asks me about.
@Alexander: This bug is about adding a "View as text/HTML" option, not about the "do this automatically" checkbox. Try looking at bug 453455 or bug 561392 instead.
I see parity-opera tag -- you can add chrome as well. Content-Type: text/x-java-source are displayed there automatically as text whereas in FF I can only open with another app or save.
But can Chrome view arbitrary unknown MIME types as text, or just text/* types, or does it just know about some specific MIME types such as this?
Even if Firefox was improved to support unknown text/* types (viewed as text/plain), this would be a great improvement. Almost all files that I can't view directly in Firefox due to this bug have a text/* type.
See Also: → 196078
Product: Core → Firefox
Version: Trunk → unspecified
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-opera
Whiteboard: parity-opera
Assignee: jduell.mcbugs → nobody
Status: ASSIGNED → NEW

Addressing this issue would help a lot of power users. I think all that's needed is the capability to set somewhere (even about:config) that all unknown text/* types should be handled as internally as text/plain.

Currently I have to use Chrome w/ an extension to render a markdown file from my local filesystem. It is loaded w/ the appropriate mime type: text/markdown which according to this stackoverflow (https://stackoverflow.com/questions/10701983/what-is-the-mime-type-for-markdown) was registered as RFC7763 in March of 2016.

There is at least one firefox extension which will render a markdown file. but it never gets that far, firefox only gives the options to download or to specify an external application for the file.

There are other text/* types that it would be really nice if they were just viewable in the browser rendered as text/plain, such as those for source files (text/x-c, text/x-java-source, ...). On my system the mime type is also associated w/ the list of applications I select from in the file manager to open those files, so I want to be able to distinguish them from one another (I want to open markdown files with different applications than js source files or script files for example). I mention this because one workaround suggested was just to tag markdown files as text/plain, but I'd rather continue to use Chrome than lose the ability to distinguish the files in the file manager.

(In reply to Michael Lippert from comment #217)

Addressing this issue would help a lot of power users. I think all that's needed is the capability to set somewhere (even about:config) that all unknown text/* types should be handled as internally as text/plain.

I disagree. It's only natural that sometimes the user will want to save the file to disk, sometimes the user will want to open the file in an external application, and sometimes the user will want to view the file in the browser. Why should we force the user to choose on an all-or-nothing basis, and moreover restrict it to text/* types?

There are other text/* types that it would be really nice if they were just viewable in the browser rendered as text/plain, such as those for source files (text/x-c, text/x-java-source, ...).

Indeed, Moreover, there are many text-based file formats out there - not just those that have text/* MIME types (e.g. application/xml, and apparently application/javascript and application/json exist as well).

On my system the mime type is also associated w/ the list of applications I select from in the file manager to open those files, so I want to be able to distinguish them from one another (I want to open markdown files with different applications than js source files or script files for example). I mention this because one workaround suggested was just to tag markdown files as text/plain, but I'd rather continue to use Chrome than lose the ability to distinguish the files in the file manager.

What kind of "system" is this - an operating system, or a website with an associated file manager?

The MIME type is for specifying what kind of file it is, not what the user agent is to do with it. We shouldn't force anybody to misdeclare MIME types in order to work around browser restrictions. We should fix the restrictions.

(In reply to Stewart Gordon from comment #218)

I think you completely misunderstood what I was getting at, because your final statement is what I was saying (well attempting to as it obviously wasn't as clear as I hoped).

All I was saying is that if a file is identified with a mime type of text/* that it is text, and firefox displays text just fine as it currently does with text/plain. So firefox can handle any text file it doesn't explicitly have another process for as text/plain to display it in Firefox, and that should be an option in addition to save, and specifying an external application for handling that file.

I was not requesting that the user choose on an all-or-nothing basis at all, I wanted to add an option that doesn't exist at this time, but should for text/* types because the support is already baked in.

Just a restate for my comment #57 from 16 years ago with a slight update... it is still valid

If I try to download a text/almost-binary-whatever (such as /etc/sendmail.cf), I expect a dialog asking
what to do:

You are trying to view text/almost-binary-whatever content...
( ) Save to disk...
( ) Show in browser as text/plain
( ) Open with program...
[x] Always do the same for this type
[OK] [Cancel]

Just my 2 EUR cent...

(In reply to Michael Lippert from comment #219)

(In reply to Stewart Gordon from comment #218)

I think you completely misunderstood what I was getting at, because your final statement is what I was saying (well attempting to as it obviously wasn't as clear as I hoped).

That final comment wasn't aimed at you personally. Sorry if it sounded like it was. Really, I was commenting on the suggested workaround you made reference to, rather than on your comment itself.

All I was saying is that if a file is identified with a mime type of text/* that it is text, and firefox displays text just fine as it currently does with text/plain. So firefox can handle any text file it doesn't explicitly have another process for as text/plain to display it in Firefox, and that should be an option in addition to save, and specifying an external application for handling that file.

I was not requesting that the user choose on an all-or-nothing basis at all, I wanted to add an option that doesn't exist at this time, but should for text/* types because the support is already baked in.

Which is basically what this bug ticket is asking for all along. I was saying that it shouldn't be restricted to text/* types, because other types may also be text-based formats. Another very good example of this is PGN (which seems to be represented by various application/* types).

Backlog grooming: bugs without an assignee cannot be P1.

Priority: P1 → P3

In December 2000, just shy of 21 years ago, comment number 6:
"Marking as NEW so someone will either mark it as WONTFIX or INVALID."

Status today, 25 Aug 2021 (30th birthday of Linus announcing his OS in Usenet):

"Status: NEW"

And I see multiple patches attached to this ticket from various points over the years. This is so disheartening.

Encountered this bug today trying to get a plaintext format (with the mime type application/<something>) to display as plaintext in the browser rather than Open With > Firefox (and opening a new window.)

Is there still no workaround for enabling this type of functionality, even by modifying config files in the profile? I tried messing around with handlers.json (the file that holds the mime type preferences set in about:preferences under the "Files and Applications" header) but had no luck.

Some content types in about:preferences permit users to select "Open in Firefox" while others don't. Where is the safelist of permitted content types for this behavior? Could a simple solution to this bug be to add an about:config flag that would allow power users to select "Open in Firefox" for any content type?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: