Closed Bug 8589 (ExternalViewSource) Opened 25 years ago Closed 14 years ago

make view source optionally open in text/plain helper app

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
seamonkey2.1a2

People

(Reporter: csbooton, Assigned: smontagu)

References

Details

(Keywords: helpwanted, Whiteboard: [Hixie-P0][Hixie-3.0][MB][Goat-p1])

Attachments

(2 files, 1 obsolete file)

Neil's nits picked
3.78 KB, patch
smontagu
: review+
smontagu
: superreview+
Details | Diff | Splinter Review
[checked in comment 176] Patch v3
3.78 KB, patch
Details | Diff | Splinter Review
IE uses this and it can be very useful dpeending on the user, in fact several people who use IE site this as one reason to only use IE . So, how about a feature that would make it so that you have the <b>option</b> of having view page source open in notepad (or your default html editor or an application of your choice). For people editing their own pages or wanting to fix their own pages this could be a great option.
Assignee: beard → rickg
Component: Views → Parser
This would be a nice general feature, for all platforms. View source should be able to use any helper application.
Assignee: rickg → don
Don -- forwarding this feature request to you.
URL: any
Component: Parser → other
Summary: not a bug but a feature request - how about an option tomake view source open in notepad → [RFE] Option to make view source open in notepad
Target Milestone: M14
OS: Windows 98 → All
I agree, I would suggest a 'View > Source' and 'View > Edit Source' option. This could be linked at bug #14526
*** Bug 11628 has been marked as a duplicate of this bug. ***
QA Contact: beppe → paulmac
assigning Paul as QA contact
I don't see that this is necessary. As far as I can see you'd only want to do this to edit the source, in which case bug #14526 covers this within Composer. It's not as if Notepad has a huge number of features, so the page source editor could only be better. A better idea might be to allow disabling of Composer and redirecting all "Edit Page" requests to a user-defined editor (eg Notepad).
What reasons are there to want to do this? For those who do, what features in the editor would make you use it instead? Can you submit bugs on them?
*** Bug 17203 has been marked as a duplicate of this bug. ***
All it would take to satisfy the original RFE would be to make the plain-text editor (designed for Mail/News) available on a menu in a form that would not attempt any html->plain text or plain text->html translations. This would eat notepad for breakfast. But there is a better way to provide a general solution - allow some applications defined in the Prefs UI to be "manual"-only. What reasons for making an arbitrary external app available from Mozilla for viewing/editing source? The answers don't start with notepad. (The reporter failed to mention that notepad is the *default* for viewing source with IE - and there is nothing as useful as Navigator's View Source available.) 1. To cater to the needs and wishes of those who prefer to mostly use Mozilla without being locked into a Mozilla-only environment. This should be reason enough, but consider: those who most need easy access to multiple ways of working are the very web professionals who are about to find out that Microsoft-centric semi-adherence to HTML4, CSS, DOM, etc isn't going to be enough any more. Do you really want to make it harder than necessary for these people to go from viewing a page with Mozilla/Nav 5 to viewing/editing it with the tools they are used to using or even, in some production environments, must use, when there are so many little gotchas they may find in their code viewing it in Mozilla? 2. Workflow. This goes with 1. Without this feature, to use any external app requires saving the source file (navigating to some specific location if that matters), opening the helper app, navigating to the location where the file got saved to to open it. Now imagine that the snippet of source you thought you'd find in that page isn't there. Only tens of seconds wasted, at most, but anyone used to working with any sort of programmer's editing environment is going to be annoyed. With the feature, the file would come up in the app first, and whole sequence of saving and navigating the directory tree would only be needed if there is any reason to keep the source for later. 3. No matter how good view source and compositor may be or become, they can't ever be the best for all purposes. For example, with Textpad <URL:http://www.textpad.com/> I can set up syntax highlighting however I want, and do regex searches and replacements in the source file. With Macromedia's Dreamweaver, <URL:http://www.macromedia.com/software/dreamweaver/> it is possible to edit a typo or even add elements without taking any chance of messing up the formatting of a source file prepared by a database->web->database->web gateway. There are also editors that present a navigable DOM of the entire page - allowing quick navigation to the code for any part of the page. Some helper apps can reliably parse HTML and give an accurate word count or other stats. And then there are the graphical front-ends for HTML Tidy <URL:http://www.w3.org/People/Raggett/tidy/#download>. Some of those features may be nice to have within Mozilla, but Mozilla can't be everything to everyone. (Personally I don't feel inclined to submit RFE bugs for composer or view source that would add entire new features before late beta at the earliest, when those features are already available to me in other apps - the engineers are busy enough now as it is. Time enough later to play feature-catchup. Having said that, the RFE already in bug 14526 (dual-mode editor) is the first I'd ask for, and integration of HTML Tidy is the second.) 4. It needen't be hard to do this properly. There is a simple and completely general way that this could be done: allow [New] apps defined in the Applications pane of the Prefs UI to record whether a given helper is "Auto" or "Manual" (a simple flag). A manual app would normally be set up for a mime type that already has an auto app defined, and would be used only as a user-triggered alternate. Auto apps would be invoked by default triggered by mime type as now, whereas manual apps would be added to a "Helpers ->" submenu or possibly an "Applications" menu as prefs.js or the registry is read in at startup. The user could invoke on the current file whatever helper app is useful in a specific circumstance with just a few keystrokes or mousing actions - and invoke a different one five minutes later. This would be a completely general solution to the problem of allowing choice during a session, without unhooking the default application for any action. Anyone who has ever taken a tech support call from someone who has unhooked a default app (in any environment), or can imagine it, will understand why it would be good to allow the use of alternates without unhooking the default app. (Allowing Composer to be disabled would be a horrendous example of a set-up for a nightmare tech support call). 5. Sometimes the added value of the syntax highlighting that view source does isn't worth the time it takes. If all I want to do is grab two lines out of a stylesheet in the <title>, I don't *really* want an unknown wait first. View source would have to be consistently an order of magnitude (base 16) faster before this concern would become a total non-issue.
Move to M20.
Another reason you might want to use notepad: mozilla's view source thing is hard to copy text out of. It tries to ignore the less-than and greater-than parts of HTML tags when you copy text out.
This sounds like a bug in Mozilla, not support for this bug. It's probably already been fixed by now or at least been filed by someone.
spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com
QA Contact: paulmac → sairuh
Move to "Future" milestone.
Target Milestone: M20 → Future
*** Bug 43073 has been marked as a duplicate of this bug. ***
pardon the spam: moving view source bugs into xp apps: gui component.
Component: Tracking → XP Apps: GUI Features
Ccing myself and Hurricane (rcassin@supernova.org) I think this feature would be nice and is close to bug 35268, but should be kept as a seperate feature as one might want a seperave view source program vs external editor.
Summary: [RFE] Option to make view source open in notepad → [RFE] Option to make view source open in text\plain helper app
Summary: [RFE] Option to make view source open in text\plain helper app → [RFE] Option to make view source open in text/plain helper app
*** Bug 58438 has been marked as a duplicate of this bug. ***
*** Bug 59155 has been marked as a duplicate of this bug. ***
Here are my comments from bug 59155 and a bit more: I was reading n.p.m.wishlist, and I saw a lot of references to IE's loading source code in notepad. So here's an rfe. 1) Include the ability to hook the View Source command up to the program that is specified for "Edit" in Windows File Types (Win only). In Windows IE this is usually Notepad, Word, or Frontpage. 2) Include the ability to specify a program to view the source code in. (I would use xemacs on unix) Implementing this would give many users an advantage by being able to use their favorite editor to do all the things that mozilla view source does and more (cut and paste, syntax highlighting, regexp searching, etc.). It would also get rid of many complaints about the syntax coloring issue (bug 52154). As far as I know, the way IE does this is to pass the temporary file from the cache to the external program via command line. I think this should be included in mozilla1.0. Why reinvent the wheel (view source) when there are so many great text editors out there. I think it should even be default if implemented. > This sounds like a bug in Mozilla, not support for this bug. It's probably > already been fixed by now or at least been filed by someone. What do you mean by that?
*** Bug 60424 has been marked as a duplicate of this bug. ***
*** Bug 60597 has been marked as a duplicate of this bug. ***
Sorry for the dupe..this is a must-have for me. cc:ing self.
Hello, my bug was marked a dupe. Adding CC.
Mozilla should have a built in text editor for the default helper app that comes with it, but someone should be able to change it to notepad (why they would is beyond me). This Mozilla text editor should have an option to make all tags a certain color based on what they are.
I also agree that composer should not be used at all to view source. It would make a lot of people twiddle their thumbs. Twiddling thumbs is bad.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
*** Bug 63497 has been marked as a duplicate of this bug. ***
*** Bug 63497 has been marked as a duplicate of this bug. ***
My $0.02 The built in view-source function doesn't do what I want it to do. gvim does everything I want it to do. Even if the built in view-source did what I wanted, I already know how to use gvim and it's set up to my liking. This feature request is *VERY* desireable to myself and other developers in my group. With more developers using your broswser, you'll get more pages made for your browser, and therefore more users using your browser.
*shrug*, if you want to do it go ahead; we're accepting [good] patches. however you should be able to pick a text helper app for composer [which can actually function as a browser]...
reassigning to ben.
Assignee: vishy → ben
I too would like a pref to choose an external editor/helper app. What about for embedding where a context click could have view source but composer isn't installed? I guess embeding vendors could whip that up easily.
Hardware: PC → All
I personally think that a simple text editor with ability to display line numbers and replace/search for text could be included in mozilla and be the default helper app. ie: the default helper app would be "texteditor" or something (and could be changed) which would let mozilla know to open the text- editor built into mozilla. Composer is no option since everyone doesn't install it (I think). The text-editor could be a simple XUL Box with a menu bar and an XUL Frame, and a status box at the bottom. The status box would show the line:col. This needs to be fixed soon as this is the _MAIN_ reason keeping a lot of people from using Netscape-type browsers.
line numbers sounds like a good rfe for view source, filed bug 70868. currently composer ships w/ navigator, i never got around to completely splitting it out.
Blocks: 78106
10 dups according to http://bugzilla.mozilla.org/duplicates.cgi. Marking mostfreq.
Keywords: mostfreq
Excellent commentary, Mr. Richardson. You've made a compelling argument. Adding CC. KNode, a KDE newsreader, allows you to set an external editor. Screenshot: http://www.kde.gr.jp/help/doc/kdenetwork/doc/knode/HTML/knode- composer-settings.png Perhaps the KNode source could point the Mozilla team in the right direction? http://knode.sourceforge.net/
No, we can switch the HTML composer into a plaintext editor if we need to, and I'm working on some stuff which will allow a document to be loaded directly into a plaintext editor (currently, the only way to access plaintext editing in the editor is to open a .txt document, or to go to the Debug menu and click Plaintext Editor) What do we want here? A menu/button in the view source window that will pop open an editor in plaintext mode with the HTML source there? ...I can do that, it shouldn't take long at all. Just need a little feedback and I'll be on my way.
I would vote for an option in preferences to define the external application (if any) to be used when viewing source. a separate menu item might be annoying, especially if it was not available by right-clicking the page.
Just my .02 I would like to see a menu option in the main mozilla browser (like IE) but could live with the menu under the view source window. Seems like an extra step to me. I think that the most important part to this bug is to allow someone to select what application they want to use as an editor (not just the one that comes with mozilla). For me it's TextPad. In IE, I can change my editor to TextPad. This is the main reason why I do not solely use mozilla.
rcassin: I think the best option would be a simple notepad-like editor built into the source (possibly composer embedded in a small window - if it comes up fast) as the default helper app. Then composer could be a secondary helper app. Finally one could pick something on the operating system. This default helper app need not do more than word-wrap / non-word wrap, search, replace, [cut, copy, etc], print, and view and save in either unix, mac, or windows text format. The basic idea here is it should be fast. Faster than loading a browser window hopefully, and faster than loading composer. Possibly, also a different thread so it doesn't crash with Netscape (in case Netscape crashes). If that wouldn't work, then it could be a seperate xpcom program. (Maybe there are even simple xpcom text editors out there).
By Netscape I meant Mozilla, and don't forget the ability to open files and spawn new text windows.
Netdemon: We already have plaintext editor capabilities in the editor. Go into the editor and open a .txt file. The HTML composer changes into a plaintext editor. My suggestion was to have a way to open the page you're at in the browser open in the plaintext editor. There is an easy way to get this done, and it works as a temporary fix to this bug. I realize that we still couldn't open the source in an external editor, but something is better than nothing?
rcassin, *sigh*. As I said, I don't want composer loaded when all I want to do is view the source, and maybe do a couple changes and save it to the disk. Maybe you coulc have a button in the view source window that could transer the document over to composer, but composer is not my idea of a text editor. Lets put it this way: would you want Word to load in text format just for viewing the source of a web page? If you look at what I said, I was basically saying that composer, although it has text editing capabilities, is not good for this. >rcassin: I think the best option would be a simple notepad-like editor built >into the source *******------{{{{{{ LOOK HERE: (possibly composer embedded in a small window }}}}}}}------****** - if it comes up >fast) as the default helper app. Then composer could be a secondary helper app. >Finally one could pick something on the operating system. >This default helper app need not do more than word-wrap / non-word wrap, >search, >replace, [cut, copy, etc], print, and view and save in either unix, mac, or >windows text format. >The basic idea here is it should be fast. Faster than loading a browser window >hopefully, and *******------{{{{{{ LOOK HERE: faster than loading composer. >}}}}}-----******* Possibly, also a different thread >so it doesn't crash with Netscape (in case Netscape crashes). If that wouldn't >work, then it could be a seperate xpcom program. (Maybe there are even simple >xpcom text editors out there).
The Plaintext Editor is NOT composer. (In fact the plaintext editor got forgotton when the component bar was added to Mozilla's status bar). The difference is similar to the difference between Wordpad and Notepad. Also, Composer 4.x had an external edit option, so this bug is 4xp.
Up to trudelle. Sounds like something Paul Chen might do?
Assignee: ben → trudelle
Sounds very useful to a tiny number of people, but almost certainly not something we'd be able to spend NS engineering time on.
Component: XP Apps: GUI Features → File Handling
What this all comes down to is a simple matter of choice. The whole basis of the Open Source movement is freedom to choose... not imposing your will or your way of doing things on others. This seems to me to be a simple matter... there would be many people out there, myself included, who would benefit from the option to choose our own editor/viewer. If you have people asking for the feature, and it would not be a huge problem to do it, why not do it? It won't effect standards compliance, or degrade the application in any way. It would simply be a feature that many people have come to expect and depend on when developing web content. Mozilla has come a long way in the past few years, and at this point may very well be a model for how to put out a quality, standards-compliant piece of software. But it's those little extras, those little features that make life easier, and help with the mainstream acceptance of Open Source projects. We should keep the spirit of choice alive, even in the small details.
and in that great spirit, you can submit a patch...
...and if anyone chooses to attach a patch, we'll certainly spend the time needed to consider it.
*** Bug 120550 has been marked as a duplicate of this bug. ***
Please note that this would also provide a (pretty good!) workaround for all the bugs relating to the way 'view source' processes the HTML (and accordingly fails to represent it accurately).
But I hope you will not remove standart View Source?
I think we should dump our internal view source and use external editors for the view source and view selection source commands, working as follows: Windows ------- View Source on non-local files should save the file to a temporary place and launch the editor appropriate for the file's MIME type (e.g. if you are viewing a text/html file it should launch the program associated with the Edit command of text/html files, for image/png it should similarly launch the default Edit command of image/png files). If there is no Edit command then for text/* MIME types it should use text/plain's Edit command, and failing that it should use the MIME type's Open command, and failing _that_ it should use text/plain's Open command, and in the worst case it should just launch notepad.exe. Linux and Mac ------------- Similar, using the equivalent on these platforms. Linux would fall back to $SOURCE_EDITOR and $EDITOR. View Selection Source should trim the file before doing this (although if you could get it to pass some LISP code to Emacs that just selects the selection that would be even better of course).
Whiteboard: [Hixie-P0][Hixie-3.0][MB]
Could you tell us, please, why do you think that user shouldn't have an ability to view page source with the included comfortable View Source application. Yes, you are right, there should be an option to open source in external application, or to replace standart View Source with external application. Some people prefer to use Notepad or HomeSite, and now they have no ability to use it. But why do you think that there is no user in the Earth that could prefer to use internal View Source??? For example, I want to have BOTH options, because usually I use View Source, but sometimes I want to open it in external HTML editor, and I saw those who think the same. I can understand, that you try to make Mozilla absolutely same as Internet Explorer (however, I cannot agree with this position!), but why do you think it should have all the Explorer defects and imperfections??
I agree with Alexander. Just give the option to change it to editor, notepad, or whatever else.
hixie: i don't think it is a good idea to dump the internal 'view source' viewer, since it got pretty cool with the time. It is much better now then what most of the non technical users will have.
FWIW, in my opinion we should definitely delegate whatever we can to the OS currently running; that means opening the source in the user's favorite text-editor. If you would desperately want a XUL view-source application (why?), I'm sure it wouldn't be hard (after this was fixed) to revive it as an XPI on mozdev.org.
> in my opinion we should definitely delegate whatever we can to the OS > currently running I disgaree - after all we are not delegating a mailreader or newsreader to the outside apps, even if we could. I like the current view source and I do not even need an external app in 99% of the cases. And after all, opening a window in Mozilla is faster than starting some external app. In any case, even if we end up getting rid of the internal viewer *it's definitely a separate bug*! Let's make the external app *an option* as this bug requests, live with it for a while, see how it works and then we'll be in much better position to decide whether we still need the internal view source.
> I disgaree - after all we are not delegating a mailreader or newsreader to the > outside apps, even if we could. This argument is moot, since we aren't because we can't (yet). See bug 34819, bug 11459 and bug 56478.
If it's decided that the internal viewer should stay, I'm all for modularizing it so that people who don't intend to ever use it don't have to install it (like with mail/news, psm, etc).
Really, delegating it to another app is making our code depend on another application working/existing/etc. How do we know that the OS has what viewer we delegate it too? Say you choose xemacs in linux: People can install linux without xemacs. If you think its alright that they have to do a one-time setting, think about developers who might install it many many times and try many different profiles. Think, also, about all the developrs who have worked on it. You are going to throw their work away even when some people like the current view source? If we make it an XPI, at least half the people running mozilla/netscape won't know they can get it. I agree with modularizing it as long as it comes by default on the .zip and .tar.gz binary files and also exists by default when building with the source tree.
> Could you tell us, please, why do you think that user shouldn't have an ability > to view page source with the included comfortable View Source application. Because we are a web browser, not a source viewer. Source viewing should be left to applications that are good at viewing source, just like we let other applications handle the rendering of movies, word documents, etc. Platforms always have an editor of some kind. On Unix systems the editor is specified using $EDITOR as a last resort. All three main platforms have official ways of finding the user's preferred editor. (This should certainly not be a Mozilla-specific pref.) Note that if we don't let Mozilla integrate with other mail/news applications, that that is a bug and not a feature.
Assignee: trudelle → doron
Severity: enhancement → normal
Component: File Handling → ViewSource
QA Contact: sairuh → pmac
Summary: [RFE] Option to make view source open in text/plain helper app → make view source open in text/plain helper app
> e.g. if you are viewing a text/html file it should launch the program > associated with the Edit command of text/html files, for image/png it should > similarly launch the default Edit command of image/png files That would be completely useless. If I choose `View Source' for a text/html file, I expect to view the source of the file (`<!DOCTYPE HTML PUBLIC "-//W3C...'), not the page itself mangled in FrontPage or Composer. And if I choose `View Source' for an image/png file, I expect to view the source of the file (`âPNG IHDR
...), not see the image itself in PictureViewer. > Because we are a web browser, not a source viewer. Speak for yourself; I'm not a Web browser. I do, however, have five Web browsers on my computer (not counting different versions of the same browser), and *every one* of them disagree with you. They all have dedicated source viewers; and all these viewers (modulo bugs in Mozilla) have the same set of menus as the browsers themselves, an advantage which an external editor could never achieve. In theory, it would be nice if we could say `Mozilla is a Web browser, not a source viewer', `Mozilla is a Web browser, not a search tool', `Mozilla is a Web browser, not a bookmarks manager', `Mozilla is a Web browser, not a cookie manager', and so on. In many of those cases (as with mail/news) it would be nice if Mozilla's implementation of those features was implemented as a separate process. And it would be nice if I could choose to delegate those tasks to external apps. But to say that they *must* be delegated to external apps is entirely unreasonable, given that Mozilla's implementation of most of them -- including its implementation of source viewing -- is an order of magnitude better than that available from any alternative program on a default Windows or Mac OS installation.
I agree with Hixie's point (nothing new here). Moving away from an internal mozilla viewer to the OS default source viewer would be a wise choice and is a better use of limited resources. Matt your comment #65 seems wrong to me because (unless one of your 5 browsers isn't IE), IE (with what 95% of the browser market) has always defaulted to the OS when it comes to view source (textpad) in windows (there is a pref to change to a different app -- TextPad for example) and I'd bet IE does the same thing in Mac.
> I do, however, have five Web browsers on my computer > (not counting different versions of the same browser), > ... They all have dedicated source viewers In Netscape 2.0 you can edit netscape.ini and change the HTML editor. In Opera, the default viewer is write.exe, and you can change it. In IE, the default viewer is notepad. So what do you have, Mozilla, Amaya, and Lynx? > all these viewers have the same set of menus as the browsers > themselves, an advantage which an external editor could never achieve. How is a this an advantage? Now you can text-zoom and word-wrap? Is there something I'm missing? The internal viewer is slow. Viewing the source of http://www.timelapse.com/tvlink.html leaves you staring at the hourglass for 10 seconds in Moz. It's instantaneous in IE with Textpad.
I already said this in comment #59, but I believe it is worth repeathing. *This* bug is about adding an *option* to view source in an external app. Those who think that the current internal view source should go (personally, I strongly disagree) are welcome to file a *new* bug on that! To quote the original reporter: > So, how about a feature that would make it so that you have the <b>option</b> of having > view page source open in notepad (or your default html editor or an application of your > choice). (the <b> on option comes from the original reporter).
I agree with Aleksey Nogin. And I should remember some of you you again: there are A LOT OF PEOPLE wanting to use internal viewer because they think it's comfortable. If you want to force them to search for another application, that is as comfortable as internal viewer, you should remove Modern Theme because you don't like it, and remove Mail&Newsgroups because it is too slow and less comfortable than TheBat, and remove Preferences because you know better than any other people, how it should be customized! You don't want to remove Modern Theme and Mail&Newsgroups? Well... That's strange! So why do you want to remove View Source? Oh, I know! You think that it's easier to remove an app than to make it better. So, remove Navigator, because it has a lot of bugs! Ð&#65533;Ñ&#65533; до Ñ&#65533;его же некоÑ&#65533;оÑ&#65533;Ñ&#65533;е Ñ&#65533;оÑ&#65533;Ñ&#65533;Ñ&#65533; Ñ&#65533;Ñ&#65533;о-нибÑ&#65533;дÑ&#65533; Ñ&#65533;бÑ&#65533;аÑ&#65533;Ñ&#65533;!
Actually, I do want to remove mail and news (see bug 115903). And as some people have noticed, there is a concerted effort to reduce the size of the preferences. And the View|Apply Theme menu is being removed too. So all in all, we are doing exactly what you say we should be doing to be in line with removing our internal view source implementation (and its 100+ bugs). mpt: given the many bugs in our view source implementation, especially those that _change the source_ of what you are looking at, I doubt that we really are better than anything else that ships on Windows or Mac.
Filed bug 145021 for this. Please take further discussion there so this bug can return to its original purpose (i.e. letting people choose what they would like to view source with, including the internal source viewer). Another bug that might be of interest is bug 13474 (external processes/filters for textareas), which currently has a preliminary patch.
Blocks: 145021
No longer blocks: 145021
That's a great solution (see my comment in bug 145021).
Depends on: 145021
Letting my goats fix this for me, expect it done around bugzilla 3.0
Whiteboard: [Hixie-P0][Hixie-3.0][MB] → [Hixie-P0][Hixie-3.0][MB][Goat-p1]
> Actually, I do want to remove mail and news That's bad. I beleive in you, you, may be, want to remove browser too. May be, you think that all that Mozilla does, the other soft does better... > So all in all, we are doing > exactly what you say we should be doing to be in line with removing our internal > view source implementation (and its 100+ bugs). So, I totally disagree with your conception. I thought, that we are DEBUGGING, but I was not right. Actually, we are REMOVING. I don't like this process. If all will come this way, I will use Mozilla 0.99 or other old build, or Communicator 4.79, because Mozilla will use only external applications all the time. I'm sorry, but I thought that in this century browser is not ONLY a browser. I was not right. All the browsers except for Netscape are not only browsers. Netscape will be ONLY Navigator, without Mail, News, Composer, Debugger, Java, PageInfo, Security Manager, Password Manager, and even View Source. You are tired of debugging, so you say: "our product will never be better than all the others!" I do not agree with you - I think, we SHOULD try TO MAKE IT BETTER, THAN THE OTHERS! But if we will look at it as at MsOffice, which is already developed, and will never be better, then there will come a day when Mozilla will be only a browser. > mpt: given the many bugs in our view source implementation, especially those > that _change the source_ of what you are looking at, I doubt that we really are > better than anything else that ships on Windows or Mac. You say: "TheBat is better than Mozilla Mail. HomeSite is better than Mozilla View Source. And Mozilla chat client isn't the best in the world." So, all users have to search for the separate application for each small function. What's next? Will you say that Navigator isn't the best browser, and we must throw it out?? I'm waiting. P.S. I know what is your slogan. It is: LET US IMPLEMENT ALL THE IMPERFECTIONS OF MICROSOFT INTERNET EXPLORER IN MOZILLA AND REMOVE ALL THE COMPONENTS THAT CONTAIN UNFIXED BUGS! But I do not think that this is what we should do. Yours faithfully, Alexander
I don't think Hixie is saying that the Mozilla project should only make a browser. I think he is saying that the browser, mail, news, view-source, etc... should all be separate sub-projects which are optional to use. In addition, he is saying that a crasher bug in, say, mail, should not bring down the Mozilla web browsr and vice-versa. Bugs might be more manageable if they didn't affect everything else. If IE crashes, it doesn't bring down Outlook Express with it. In this senario, view-source would be available to you, but as an option. Think of an installer where it would ask you, "do you want mail/news, view- source, browser, etc...". What about people who just like Mozila's Mail app a lot, but don't care to use the browser (only theoretical...who wouldn't want to use the Mozilla browser?). They should have that choice. Why require the user to have Chatzilla, Composer, the browser, etc... when they just want mail/news? For those who think some of these components should be scrapped, I'd say that I wholeheartedly disagree with your sentiment. However, I don't think anyone is actually saying that...or actually meaning that even if their words could be misconstrued as implying that. bug 115903 and bug 145021 look like very nice solutions to me. Mozilla is supposed to be componentized in an effort to be more embeddable and to reduce unnecessary bloat. Let's not let this effort get lost in accusations that people are out to ruin the Mozilla suite...least of all Hixie. Jake
Thank you, Jake! I'm sorry, but Hixie wrote that he wants to remove View Source and he wrote "Actually, I do want to remove mail and news". >the browser, mail, news, view-source, >etc... should all be separate sub-projects which are optional to use. In >addition, he is saying that a crasher bug in, say, mail, should not bring down >the Mozilla web browsr and vice-versa. > >Bugs might be more manageable if they didn't affect everything else. If IE >crashes, it doesn't bring down Outlook Express with it. I agree with all that you wrote including what about "separate sub-projects which are optional to use". All installed components should be avialable through the menu (Tools or Window), but when one component freezes or crashes, it shouldn't crash all the others! >Think of an installer where it would ask you, "do you want mail/news, >view-source, browser, etc...". Good! I think, it's one of the best solutions. May be, simply the best solution. And one small thing... After the installing user should have an option to use or not to use by default these components, including Mail and View Source. If he installed View Source, he should have an ability to access BOTH View Source and external HTML editor from the menu/context menu or to switch it in the Preferences, like this: Source Viewer [ ][Browse...][Restore default] or this: Source Viewer ( ) Default (*) Other: [ ][Browse...] or this: Source Viewer External [ ][Browse...] Show in menu ( ) Default ( ) External (*) Both >bug 115903 and bug 145021 look like very nice solutions to me. Yes. 115903 will increase stability and make Mozilla more comfortable. As for 145021 ... May be.
Please see bug 145640 about having both internal viewer and helper application available on the menu system or equivalent.
*** Bug 143409 has been marked as a duplicate of this bug. ***
Let me just reiterate that while I believe there should be a user pref for this, Mozilla's pref dialog is not the appropriate place for it. It should be in the GUI shell -- on Windows, it's the File Types editor, for instance.
I believe it should go in the helper applications section of Mozilla not under text/plain but as application/x-sourceview or something.
Or maybe the OS under something like application/x-sourceview or text/src, but text/plain is mapped to notepad under my system, which isn't what I would want to use for editing pages, but is perfectly fine for some files. For editing pages, I would want to be able to choose a separate program from notepad without affecting my association for text/plain. I still believe the proper place for this is a permanent entry in helper applications in preferences that opens an alternate "Edit Type" window that gives more options than a manually created entry. Why does this bug depend on bug 145021? You can create the ability to open in a text/plain helper application without bug 145021 being fixed. How can you fix bug 145021 without this one being fixed, though? If that one is fixed first, there will be no view-source ability even in a helper application if someone chooses not to install view-source. Shouldn't this bug block bug 145021?
Who said the view source component should be optional?
Nevermind, bug 145021 does. /me wakes up some more.
This bug does NOT depend on bug 145021. Someone who can should change the dependency. Bug 145021 might depend on this bug. Reminder: this bug is about allowing the *option* for view-source to open in a text/plain helper application, not for *requiring* it. The summary should be changed too.
Effectively, they are the same, since the correct way to implement this (as described in comment 54 and especially in bug 145021 comment 2) would be to make the source viewer component the default source viewer component. The pref to change which source viewer you use is an OS-level pref, not a Mozilla-level pref.
Hixie, I don't know what OS you are using, but the OS I am using (W2K, unfortunately) does not provide an OS-level pref that allows me to distinguish viewing HTML from viewing HTML source from editing HTML from editing HTML source. I only have the choice of what to view HTML with (e.g. Mozilla browser), and what to edit HTML with. (e.g. Mozilla composer) I prefer the current internal Mozilla source viewer for taking a quick look at a webpage to see what was sent or how something works. I would never choose the source viewer as my default HTML viewer or default HTML editor, which appear to be the only choices this OS lets me configure. If you can inform me where the OS-level configuration for HTML source viewer is, please go ahead. We'll need the text for the release notes if your preferred solution is ever implemented.
Explorer, Tools, Options, File Types, Edit. You can add any action you like.
Ok, so as I understand it, what hixie is proposing (modified to allow view source separate from edit) is: Windows ------- View Source on non-local files should save the file to a temporary place and launch the newly invented proprietary Mozilla "View Source" action appropriate for the file's MIME type (e.g. if you are viewing a text/html file it should launch the program associated with the "View Source" command of text/html files, for image/png it should similarly launch the default "View Source" command of image/png files). If there is no "View Source" command, then it should use the Edit command. If there is no Edit command then for text/* MIME types it should use text/plain's Edit command, and failing that it should use the MIME type's Open command, and failing _that_ it should use text/plain's Open command, and in the worst case it should just launch notepad.exe. Installing the optional View Source component would then ask if you wish to associate it with the new "View Source" action on HTML (and XML?) files. Linux and Mac ------------- Similar, using the equivalent on these platforms. Linux would fall back to (the newly invented proprietary) $SOURCE_EDITOR and (the standard) $EDITOR. I suppose this wouldn't be too bad, though I really don't think it is the place of Mozilla to invent new OS level prefs for things like this. It seems far simpler to me to simply have a preference in Mozilla for what program to use for viewing source, with an option to fall back on the OS default editor. Overall, I really don't care how exactly it gets resolved, as long as it is still possible for me to easily choose to use the built-in Mozilla source viewer *and* relatively easy to choose an external helper app for viewing source as well. Personally, I would prefer to be able to choose which to use right when I choose to view source, like in IE where the "Edit" toolbar button also has a drop down to choose which editor to use. I believe that is already filed as bug 145640. (or its currently unfound duplicate.)
Yes, that is what I am proposing. Note that it also allows "View Source" (or whatever the equivalent is called) to work on images, PDF files, XML documents, CSS sheets, JS scripts, and other file types which Mozilla's source viewer doesn't yet support. (I'm not convinced this is a "new" pref. Absolutely no new UI is added anywhere.)
Just wanted to note again, I am the wrong person to be the owner of this. Probably belongs in file handling or whatever component handles helper applications
-> File Handling then
Assignee: doron → law
Component: ViewSource → File Handling
QA Contact: pmac → sairuh
what happens if i try to view-source: a never ending file? (i've asked someone to check about mozilla's view-source: handler)
view-source: is a hack and shouldn't exist... if you mean "what happens when you the view the source of a never ending file", then I guess the same happens as when you download an infinite file and open it in a helper app (since this is effectively the same thing).
*** Bug 151319 has been marked as a duplicate of this bug. ***
Hixie: I don't agree with View Source being removed, but I do agree with it possibly being made as something that isn't required for the installation or building of Mozilla. Perhaps it could be hosted on Mozdev and improved by outside programmers who could improve it, make it editable, add line numbers, remove all issues, etc. When people want to use it, they could be given a link to the .xpi on Mozdev when they choose View Source but have no helper application defined. Once all the issues are resolved by developers who have time to work on this, it can be reintroduced as part of the tree.
*** Bug 158942 has been marked as a duplicate of this bug. ***
*** Bug 162091 has been marked as a duplicate of this bug. ***
Alias: ViewSource
I'm a web developer, and I can't use Mozilla for development because of this bug. I absolutely vote for user choice for what does View Source. You CAN'T make a better text viewer than what I use, because what is best depends on user prefence. I use Wordpad, hubby uses Editpad. I don't care what features or bugs are present or absent in a text viewer, unless it looks and acts EXACTLY like Wordpad, it is *not* best for *me*. Unless it looks and acts exactly like Editpad, it is *not* best for my husband. If I need a WYSWIG editor for some reason, I want my old out-of-date version of Dreamweaver - NOTHING else. And I want to view graphics in *my* chosen graphics program, which is not the PaintShopPro hubby uses. Before Mozilla, he used Navigator, I used IE. With Mozilla, our themes and skins and preferences and plugins are completly different. Our browsers look MORE different now than when we were actually using different browsers! In any scenario, increasing user choice is the best thing.
Status: NEW → ASSIGNED
THIS BUG AND ALL BUGS IN BUGZILLA ARE FOR TRACKING DEVELOPMENT WORK. IF YOU WANT TO ADVOCATE SOMETHING, PLEASE GO SOMEWHERE ELSE. /dev/null is a good choice. newsgroups are an ok choice. Also, please don't futz with bug states, law didn't authorize you to accept the bug on his behalf.
Alias: ViewSource → ExternalViewSource
Status: ASSIGNED → NEW
Fine, shall I create a patch which does this and watch it be rejected?
It will be accepted if: 1) UI for the user to choose the program 2) cross platfrom 3) current viewsource behaviour is default However, if you really like getting rejected, I can do that too.
For doron's #1 on the last comment... The backend doesn't have to be done by the same person as the UI.
This feature is definitely needed if you are doing web development. At the moment, you really can't trust mozilla to show you the source as it is. Sometimes you make a change to your code and something doesn't render quite right. At this point you can't just open the source and see what might be wrong. When working on Windows, I usually keep IE open just for cases like that. (On linux I need to use a perl script that retrieves the page and dumps it to a file, which I then open with emacs. This is a total pain, since you can't easily paste a URL from Mozilla into the console window.)
Blocks: 145640
Blocks: 145021
No longer depends on: 145021
QA Contact: sairuh → petersen
If nobody more knowledgable about Mozilla is actively working on this, I'm going to try to take a stab at this this weekend, starting by adding do-nothing backend options. (I think bug 57724 is the highest-priority bug in Mozilla, although the silly Netscape people don't seem to agree; and fixing this is the easiest way to get a work around for that bug. Until one of these two is fixed, View Source is useless.) By the way, this bug seems to be in the wrong component.
correcting component
Component: File Handling → ViewSource
foo
Assignee: law → doron
Nathanael, please consider a patch of Bug 13474 : external processes/filters for textareas
Good God, Mozilla is poorly documented. I can't figure out how to add a backend pref. --Nathanael
Consider that a request: if anyone can point me to documentation indicating how to add a back-end pref, or to which files back-end prefs are listed in, please do.
I would like to see View Source be able to use an outside editor - such as VIM or GVIM. I think Doron's suggestion will allow that, but if not you should be able to configure a editor specifically for viewing source. I haven't played w/editing source via Mozilla, but there also you should be able to configure the editor to use. Great work - keep it up!
I vote for a new pref under navigation or Advanced, allowing the user to select ------------------------------------------------------------ View Source uses: [ ] Internal viewer (*1) [ ] Load source in Composer [ ] Use external viewer/editor [full pathname input box] (*) ------------------------------------------------------------ (*1) even if the internal source viewer becomes better than all existing editors, there should still be a choice... (*) Where the user could enter a full executable pathname like: c:\windows\notepad.exe %1 or c:\utils\q.exe %1 (QEdit 3.0 rules ;) or in linux \usr\local\bin\joe \usr\local\bin\vim ...or whatever Of course the source would be saved to a temp file and then passed as argument to the editor/viewer of choice. This is TOTALLY unrelated to the issue of "if Composer adds a plaintext editor", "if some user wants to use Composer", "how great composer is", "Why someone thinks notepad.exe sucks". Mozilla is and should continue to be about CHOICE. If the user prefers the built in viewer, fine, it should be an option. If someone wants to load the source in composer, FINE, it should be an option, and finally there should be an option to use whatever third party app the user wants. Simple, isn't it? I'm not making names... but it seems that some folks are too interested in "defending" the status quo against any improvements. And "freedom of choice" is clearly an improvement in my book. [Yes, matty@chariot.net.au, I'm talking about you ;)] Just my $.02 Fernando
I vote for this variant too. Yes, this will be the best solution! And you should probably add special option for the case if someone on mozdev.org will present alternative mozilla-based source viewer. (It could be connected in [full pathname input box])
Mozilla is also about contributing code. So unless you can help in that area, adding "I too want this" won't really help at all.
Please read comment 109 again. I'm willing to do this, and I can contribute code. But I simply can't find where or how back-end prefs are put into the codebase; the Mozilla codebase is a maze. I spent two days looking. If someone can tell me where to find information about this, I'll start on it. :-P
Nathanael, I doubt that I know any more about the mozilla code base than you do and may be totally out of line here but, since nobody else is responding to you, it appears to me that nsExternalHelperAppService.h, and its parent directory, would be a good place to start looking in order to fix this bug. http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.h However, based on your comments and my own short foray into the mozilla codebase a while back, I wouldn't be surprised if you've already found this file and, in the process, discovered that very few of the mozilla headers have even the most cursory description as to what the class they define is supposed to do. This means that, if you're new to the code, finding where a particular task is carried out requires first browsing through a gazillion files that aren't what you're looking for before you finally stumble upon anything remotely relevant to what you want to do. There're also a lot of headers that appear to have been removed from the codebase, but are still referenced in various other files. For instance, nsIMMEInfo.h and nsIServiceManger.h (which is, AFAICT, now nsIServiceManagerObsolete.h). But I'm getting off-topic here, so I'll digress :-)
write code first, we can deal with prefs later
If you want to "add" a back-end pref, you simply ask the pref APIs (see nsIPrefBranch and nsIPrefService) for the value of that pref. You should make sure that either there's a default value in all.js (considered the preferred way, for some reason, perhaps as documentation) or that you fill in the out parameter with a default value before the function call to the pref APIs so that if the pref is not present (and they will return a failure nsresult), the out parameter will be correct (since they won't modify it in that case).
*** Bug 198758 has been marked as a duplicate of this bug. ***
*** Bug 69329 has been marked as a duplicate of this bug. ***
Depends on: input-helper-apps
Marked dependent on bug 46135 for helper input applications, so that the text/plain helper application will be an editor instead of an (optional) viewer.
Memorializing the pertinent documentation, the result of bug 61408: http://bugzilla.mozilla.org/attachment.cgi?id=112432&action=view
Depends on: 61408
Blocks: majorbugs
Taking, guessing 1.7a. Doron: if you want this earlier, please keep bug 46135 in mind. Just in case you or anyone else does, here are the pertinent excerpts: +++ profile/defaults/mimeTypes.rdf 23 Jan 2003 20:16:09 -0000 @@ -1,11 +1,60 @@ <?xml version="1.0"?> -<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:NC="http:// home.netscape.com/NC-rdf#"> +<!-- + This file is used as a persistent data store for helper application + information. - <Description about="urn:mimetypes"> + The root of the data is the <RDF:Seq about="urn:mimetypes:root"/>. This + contains one <RDF:li/> entry per MIME type. Each <RDF:li/> entry corresponds + to the "urn:mimetype:major/minor" resource, where "major/minor" is the MIME + type. For example, for HTML we would have "urn:mimetype:text/html". + Typically, this resource will be in the <RDF:Description/> node which has the + corresponding "about" attribute. + + Each "urn:mimetype:major/minor" resource can have the following properties: + + NC:Value - the MIME type string + NC:editable - a "true" or "false" depending on whether this entry is + editable + NC:description - a description of the type ("HTML Document" for text/html) + NC:fileExtensions - there will be one of these properties per extension that + corresponds to this MIME type, each one having a single + extension as its value. + NC:handlerProp - the way the type should be handled. This corresponds to a + "urn:mimetype:handler:major/minor" resource. Eg, the way + HTML is handled would be stored in the + "urn:mimetype:handler:text/html" resource + + Each "urn:mimetype:handler:major/minor" resource can have the following + properties: + + NC:useSystemDefault - "true" if we should handle per defauly OS setting, + "false" or not set otherwise + NC:saveToDisk - "true" if the data should be saved to disk, "false" or not + set otherwise. + (Note - if both of these are false, that means "open in helper app") + NC:alwaysAsk - "true" if the user should always be prompted before handling + data of this type, false otherwise. + NC:externalApplication - the helper application to use for this type. This + corresponds to a + "urn:mimetype:externalApplication:major/minor" + resource + + Each ""urn:mimetype:externalApplication:major/minor" resource can have the + following properties: + + NC:path - the path to the application + NC:prettyName - the "pretty name" of the application ("Acrobat Reader" for + /usr/bin/acroread, eg). +--> That reminds me, I need to reopen bug 61408 to ask whether NC:externalApplication and/or NC:path use input filename %substitution and/or stdin.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: Future → mozilla1.7alpha
Actually, none of that is relevant here. This could be done trivially by just changing a tiny bit of code in nsContentDLF.cpp (to not register as a handler for the internal view-source MIME type) and setting up a helper for application/x-view-source. In any case, please do not set the target milestone of a bug unless you are the assignee or in a position to control how the assignee spends his or her time. Undoing the priority and target milestone changes.
Priority: P1 → P3
Target Milestone: mozilla1.7alpha → Future
Boris, I did realize how easy this is, and in fact I did try to take it, thinking Doron had it as NEW instead of assigned (see comment 90.) I figured it would be perfect for getting back into the swing of things since I finally managed to obtain all the big three platforms at my place and am trying to put a build together on each of them. I've only got weekends for this, though. I now realize I need to submit a patch instead. Thank you for pointing out nsContentDLF.cpp.
One thing I should make clear. The reason I've not done this yet is that there is no useful concept of a "text/plain helper app" on Linux. Any proposed patch needs to address that problem usefully.
Can't we at least handle the Windows portion for now and make the behavior disabled on Linux?
If you are willing to maintain the Windows (and mac, for that matter, since it would also be easy there) code, be my guest.
Why would I want to open read-only (=most http) pages in an editor?
Perhaps you have your personal website stored on your computer and you want to make changes while you preview it. The files you're viewing don't necessarily have to be HTTP files - they can be local ones (readable and writable), too.
> Why would I want to open read-only (=most http) pages in an editor? Perhaps your editor has copy/paste buffers that you like and you want to extract code from one page and insert it into another. Perhaps your editor has hocks in to tools like htmltidy, so you can clean up the source to make it easier to follow.
One more note. If people want to open the "live" page in an editor, this depends on bug 73757
Depends on: 73757
The particular reason I would find this handy would be being able to use the same editor I generally use to easily find problems (often with javascript) in on request server side generated files (as with php) whose html source is not available unless from view source (often a result from a form submit). When there is an error on a specific line and I want to get there and see what's around it, the default source viewer isn't very effective (and will never have -or even should have- all the useful features an editor can have, such as code folding, line numbers, go to line, javascript syntax highlighting, regular expressions based search, caret browsing, easily selecting text with the keyboard, block selection, etc.). So even if you can't save the file there would be much use for this. (Note: I know that some things I mentioned are somehow supported or will be supported in the future by mozilla, but that is besides the point.)
>One thing I should make clear. The reason I've not done this yet is that there >is no useful concept of a "text/plain helper app" on Linux. Any proposed patch >needs to address that problem usefully. That seems very odd. :-/ Edit/Preferences/Helper Applications exists in the Linux builds of Mozilla as well as in the other builds, doesn't it? If not, why not? If so, there *is* a useful concept of a "text/plain helper app". So I'm not clear on the point here.
You can _set_ a text/plain helper app. But there is no predefined one, unlike on Mac and Windows. The point is, this proposed functionality should just involve saying "open source externally" and work; it should not require manually setting a helper to view source with... imo, of course.
IMHO, the current viewer is pretty good for many purposes as well. IMHO, even when this is fixed, the current behavour should be the default, at least on Linux.
Re: comment #134 "open source externally" can *never* be guraneed work on Linux out of the box. It involves depending on some external editor that may or may not be installed. View source should use the internal viewer by default and if you want an external viewer, you should select it yourself. The closest you can get is xterm -e $EDITOR or $PAGER, but this still depends on a sane user environment and the presence of xterm (for example, I use rxvt and have not installed xterm).
Re: comment #134 I don't care in the least that I will have to set a view-source application 'by hand' under Linux. At the moment I *cannot*. I am stuck with Mozilla's IMO useless internal view-source. (Useless because it can't be used to read the source of a page which is misdisplaying, due to its reparsing). I want the *option* to view source with another program. Just give me the option already.
Oh, boy. There are actually _two_ possible issues that this bug covers. And everyone reads it as covering the one they like: 1) Make view-source open in a helper and remove the ability to open it in the view-source window (or have this be a build-time option). 2) Have both be available, switchable at runtime. #1 is a no-brainer to implement except then Mozilla MUST be able to detect said helper automatically (since view-source will not work until there is one). #2 is rather difficult due to the way the content dispatch system works in Mozilla. Not impossible, and may be done with enough hacking on nsContentDLF.cpp, but not trivial.
OK, if comment 138 is the case, how about: Separate the current mozilla view-source component into a standalone helper app. Implement case 1 (Make view-source open in a helper), which is supposed to be trivial. Then ship Mozilla with it defaulting to use the new view-source helper. This means Mozilla will always be able to find a view-source helper since it installs its own, but the user to change this to something else if preferred. I guess I have no idea how difficult it would be to separate out the view-source part, though.
Boris, I think case #1 is covered in bug 145021, which was split off from discussion here. That leaves this bug as case #2, IMO.
Ah, resummarizing to make that clear. The viewer could be made a standalone app. It would still need to embed all of gecko, however. Doable. But might make view-source ridiculously slow to come up... We won't know for sure till someone does it.
Summary: make view source open in text/plain helper app → make view source optionally open in text/plain helper app
Blocks: input-helper-apps
No longer depends on: input-helper-apps
I think that one of the reasons why features take years to get implemented is that a proposal quickly grows into a philosophical discussion of how to reach Mars and design a sustainable environment up there. People, it's simple: -Current behavior: View source launces the built-in viewer. -Desired behavior: Have a pref that can be switched between: View source using: [ O ]Internal viewer (default checked) [ _ ]External application [application pathname/exe name] Is this so difficult to understand? Where the application pathname/exe could anything the user enters like: In windows: c:\windows\notepad.exe "d:\some\path\visual slickedit pro.exe" q.exe etc In Linux /usr/bin/joe /bin/whatever Why complicate things with text/plain helper?? The text/plain viewer could be set to something else. It's the application we use to view the source what we are talking about. Why mess things by tying one to the other? Just my $.02
> Is this so difficult to understand? No. But it's difficult to implement. Try it.
Assignee: doron → fcassia
Status: ASSIGNED → NEW
CCing myself and voting as I have a big interest in this bug being fixed too. My preference would be an option in Preferences to allow selection between internal source viewer and external viewer, specifiable by the user. Default to internal, to avoid Mozilla not being able to view page source. If this is very difficult to implement, it's a shame because it says something about how screwed up Mozilla's codebase is :-) I'd like to add an important point: many people are saying that the way to get an external viewer to view the page is to create a temp file and open it. This is fine for remote pages, but *DON'T DO THIS FOR LOCAL PAGES*! For local pages, simply send the existing file to the external viewer. That way, developers can know that editing a page located on their hard drive will update that page, and editing a remote page will mean they have to save a new file as the file they're editing is a temp file.
Jeremy, I agree with your concept of having both the internal view-source and allowing for setting an alternate editor for view-source. However, the only real purpose for the editor is that is provides nice line numbering, syntax coloring, searching, code wrapping, etc. But the point of the editor in this case is not really to edit. The editor has been discussed here because editors tend to have more functionality than plain text viewers. Let't not complicate things. Leave view-source as view-source. If you really want to edit a local file, open the file from the file system. View-source is a snapshot of a moment in time. For instance, what if I view-source and then have the actual file open in another editor and make a change? Should the view-source then change according to the current state or the original file on disk? I'd argue absolutely not! It should stay exactly the way it was when I opened it. Jake
For me, as a website creator, having 'view source' open in an editor where I can edit the source is infinitely more useful than a 'snapshot in time' of the page. Ideally the option should be renamed 'view/edit source'... if you want to view it, associate it with a source viewer, like Mozilla's. If you want to edit it, you can associate it with an editor. Why on Earth would you need to have a snapshot in time of sourcecode on your local hard drive? Just save a backup copy of the file if you want to keep the 'old' version. No, I would indeed like this menu item to have the ability to open in a text editor. Bear in mind that the proposed solution would still allow people like you to have that menu option provide a 'snapshot in time' of the page source, via Mozilla's source viewer; it could even be set as the default! However it would also allow people like me to set it to whatever I wish as an external text editor, and how does that negatively impact you in any way?
Well, let me put the question back to you. "Why on earth" would you need to view the source of a local file when you already have it on disk. Just open the file and you have the source. Why does Mozilla have to step in and open the file for you? Keeping Mozilla's view-source copy as a snapshot in time speeds development because then you can just refer quickly back to what you just did previously without going through any tedium in saving myfile-bak1, myfil-bak2, myfile-bak3, etc... I don't care to save them permanently. I'd rather they go away when I close the result of the view-source. A change in behavior impacts both the Mozilla coders, who have to fork code to treat local files and remote files differently, and users who expect view- source to be a snapshot in time, not the actual file you are editing (at least traditionally). A change in behavior results in more confusion and more code forking. I'll leave it up to the Mozilla coding team to determine if my code forking theory is correct or not. So, I think your idea that your way is totally inocuous to anyone else (so why should we worry about it) is a false premise. Jake
>Why does Mozilla have to step in and open the file for you? It saves time. Your method involves more steps: open in Moz, open editor, open file. If Edit Source is available, it becomes: open in Moz, select menu item. Simpler (in process, not the coding) and faster! Of course, this is more work for Mozilla coders. You say that's bad? It may be for the coders, but this isn't about the coders: this is just what some users want. So what if it's hard to implement or even smacks of Microsoft? Mozilla isn't just for its developers; it should be targeted to the audience that will use it. And if that audience wants Edit Source? Give it to them. P.S.--This discussion probably belongs in MozillaZine's forums and not the area where developers discuss their work on the bug.
Oh, where to begin... I'm not going to insult you because that would be rude, but it'd be nice if you actually thought about what I'd suggested before posting. > "Why on earth" would you need to > view the source of a local file when you already have it on disk. This supports MY argument. The 'view source' should have the option of resulting in EDITING the file (in a preferred editor), not just viewing it. > Why does Mozilla have to step in and open > the file for you? Because, when I'm viewing a webpage I'm working on, that's MASSIVELY more convenient than having to open my editor, and navigate to said file manually. > I don't care to save them permanently. I'd > rather they go away when I close the result of the view-source. And if you'd thought before posting, you'd realise that my proposal would keep this behaviour as default and not inconvenience you. > A change in behavior impacts both the Mozilla coders, who have to fork code to > treat local files and remote files differently Oh, boo hoo. They have to code something? I guess they were expecting to sit back and have the computer do it all for them. This is a feature request, of COURSE they have to put some effort into coding it. It's why it's not mandatory that they code it, but a suggestion. > and users who expect view- > source to be a snapshot in time, not the actual file you are editing And if you'd thought before posting, you'd realise that my proposal would keep this behaviour as default and not inconvenience them. > A change in behavior results in more confusion and more code forking. Perhaps. But, you know, it really isn't THAT difficult. Programming 3D games is difficult. Recognising when a webpage is local and when it's remote, enabling a custom application to handle a file's contents is... easier.
Can you guys move your discussion somewhere else? This bug is long enough as is...
I don't like the idea of an unsuspecting person being able to modify their local html files from within viewsource whether being an external application or view source itself. It should always be a copy. Why not have a way to send the filename to the clipboard within Mozilla as something other than the "file://" protocol garbage the operating system doesn't understand so you can click "Save" in the helper app and then just paste the filename in.
> I don't like the idea of an unsuspecting person being able to modify their local > html files from within viewsource 'Unsuspecting'?? "Oh no, I accidentally clicked view source, edited the source file, and saved it over the existing source." Come on. Why don't we just stop people from turning on their computers, they might damage them. Seriously, this argument is bogus, it's incredibly unlikely that anyone would 'accidentally' modify a file this way, there's probably a higher chance that they'd accidentally delete the file in their file manager. > Why not have a way to send the > filename to the clipboard within Mozilla as something other than the "file://" > protocol garbage the operating system doesn't understand so you can click > "Save" in the helper app and then just paste the filename in. Because even I'm having understanding trouble what you're proposing, so it would be far too complicated. Look, the idea of being able to optionally use a helper app is CONVENIENCE. It's incredibly convenient for me, as a web designer, to be able to view the source of a page with 2 clicks and quickly edit it. The idea of someone 'accidentally' modofying the file is so ridiculous that I think you're making it up just to support your argument against the helper app idea. Firstly, it'd be hard to do that accidentally as it is, and secondly, the DEFAULT behaviour being proposed is to use Mozilla's source viewer. In order to edit the source, someone would have to first change the source viewer in the prefs, then right click a page and click view source, then edit the source and then save the file. That aint gonna happen 'by accident'.
I think this should be taken to the newsgroups, or mozillazine forums but I'd just like to respond. We should let users know both within view source and when going to the helper application that this is a local file and saving it will modify the original file with a popup dialog warning that can be disabled from appearing again just like the security warnings. I don't think "view source" should allow it to be the original file. Instead, that should be within the Mozilla menu as "Edit Source" and View Source would just open a copy, while "Edit Source" would do what you want. View doesn't mean Edit. The copy/paste thing isn't complicated, but it would be obscure. When you open up a save dialog, you can type in the whole filename and press enter. Because of that, if you could copy the filename (text) to the clipboard within Mozilla, you could just paste it in a "Save" dialog within your favorite text editor. This raises the issue of how you would tell Mozilla to copy it to the clipboard.
My 10 votes are used up on more important things. However I'd like to note that in limited fashion I still use Netscape 3, and view source in it opens the page in the same text editor I use to maintain my web site.
Those interested in an unofficial solution can look here: http://mozex.mozdev.org/
Moses, Thanks for the reference to mozex. I'm using it now to write into this textarea in vim. Very neat. However, it is not really that usable since it lacks keybindings, doesn't override the original keybindings, and has clunky context menus to access all of its functionality.. I don't think it should preclude a more "official" solution. Thanks. -Chris
I don't know how many people here are Mozilla users vs. Mozilla Firebird users (as I am now but wasn't when I heard about this bug), but I figured I'd throw out the fact that there is a separate bug for this in Mozilla Firebird: bug 172817. If you use Mozilla Firebird, bug 172817 is what you want to track. It's targeted for 0.9, which may or may not mean much in reality, but I have no doubts it will be fixed by 1.0 (guesstimate of ~summer 2004) as it's a big point for many IE developer/users. Thus, I recommend you cc yourself to that bug and switch your vote from this bug to that one. In all honesty the Future target and the helpwanted keyword on this one aren't especially promising for an imminent fix. Thanks for reading, and sorry about the bugspam for the Mozilla (not Firebird) users.
Product: Browser → Seamonkey
(In reply to comment #148) "Mozilla isn't just for its developers; it should be targeted to the audience that will use it. And if that audience wants Edit Source? Give it to them." EXACTLY. If FireFox doesn't offer the useful functionality of the dominate browser (which is also free), plus more, then why bother to switch to FireFox?
(In reply to comment #147) ""Why on earth" would you need to view the source of a local file when you already have it on disk. Just open the file and you have the source." Jake, when writing HTML pages and you have linked them all together, the next step is to run it locally as the end user would do to make sure everything works as you intended, like links, paths to graphics, layout, etc. While in this debugging stage, it is far more convenient to right click, view source, and edit it if needed directly from the area you are looking at, instead of searching for the right file, which could be time consuming if you have a large website. It is offered in IE, which dominates the browser market. If you want to make a competitor to something, the worse thing to do is leave out useful functionality.
Editing a file on disk would be generally useless for me (except when developing the templates), since I don't use static pages but CGI w/ templates. Yet it is nice to be able to sometimes add a few words and then copy/paste that into my template. Then again, probably 90% of people writing pages write static pages (but the ones who write the most pages write CGI).
No longer blocks: majorbugs
No longer blocks: input-helper-apps
I don't see the importance of being able to edit the actual file you're looking at. As I understand it, when you view the source of any page in IE what you actually get is a copy of the file that's saved in a temporary directory. That behavior seems perfectly adequate; what people seem to want mainly is the ability to /view/ a file in a better app (with syntax highlighting, reformatting, whatever), rather than in-place editing. Voting for this bug.
When you view a *local* page in IE you actually get the real file, not a copy. This is very useful for developers who have instant access to a file on disk from his browser.
ViewSourceWith extension does this quite well. Is there a way to implement all its functionality in Firefox?
ViewSourceWith extension works fine in SeaMonkey 1.1.3 I'm voting for this. I seem to recall Netscape Composer had a "Edit with ..." menu option. ViewSourceWith opens CSS and JavaScript files as well, but not "Selection source".
From what Simon stated on IRC today, SeaMonkey trunk has most things needed for supporting this due to using the toolkit view source, but some navigator.js magic is still missing.
Attached patch Patch (obsolete) — — Splinter Review
Calls to viewutils.js copy-pasted from browser.js
Assignee: fcassia → smontagu
Status: NEW → ASSIGNED
Attachment #296387 - Flags: superreview?
Attachment #296387 - Flags: review?
Attachment #296387 - Flags: superreview?(neil)
Attachment #296387 - Flags: superreview?
Attachment #296387 - Flags: review?(neil)
Attachment #296387 - Flags: review?
Eww, that invokes the sucky toolkit view source window (OK, so it does print preview which we don't so it's almost sucky).
I want to add a couple observations, being a heavy user of Greasemonkey (http://xsidebar.mozdev.org/modifiedmisc.html#greasemonkey), and also of Stylish (http://xsidebar.mozdev.org/modifiedmisc.html#stylish). I do have the ViewSourceWith extension and I sometimes use it to fix this bug, but I don't have much use for these tools in editing my own web sites. These tools are becoming more popular for editing other people's sites. Opening external CSS and JS files without ViewSourceWith is nearly impossible - you have to View Source, search for the link and script elements, then most often you have to piece together the URL, paste that into Location then either view it or save it... etc. With ViewSourceWith you can do this in two clicks (from the context menu). Oh you can get the links from View Page Info - Links, which is easy if the list isn't too long. Viewing original page source is no problem, I have the choice of the Mozilla view source or ViewSourceWith options or Composer (which also has the ViewSourceWith menu), however at times I miss having the "Edit with..." option in Mozilla's View source - I will usually copy-paste the code. The biggest annoyance is View Selection Source. I finally figured out I can get the entire page in WYSIWYG-source by Select-All then View Selection Source, or of course a fragment by selection. This is important for two reasons - large pages are hard to search through (for elements you want to remove, for example), and the DOM source is sometimes different (for example when trying to match inline style attributes). When you select an area you want to copy, View Selection Source almost never selects the elements you need to copy, and it can be extremely hard to reselect the proper area, and if you copy everything you end up losing your place. Some option of opening the selection in an external editor, or at least an "Edit with..." option I think is something to consider. More and more people are using these tools every day, even if they aren't using SeaMonkey.
QA Contact: chrispetersen → doronr
Target Milestone: Future → seamonkey2.0alpha
This bug is open but targeted for seamonkey2.0a1, which has been released a long time ago. Please set the target milestone to an appropriate value, "---" if it has no specific target.
smontagu, do you still want to work on this? (BTW, regarding Neil's comment # 168, I think we should eliminate the duplication of view source windows in SeaMonkey anyhow and achieve anything we want special in SeaMonkey with an overlay on the toolkit one.)
Target Milestone: seamonkey2.0a1 → ---
This is not really on my radar any more, no.
Assignee: smontagu → nobody
Status: ASSIGNED → NEW
QA Contact: doronr → view-source
Comment on attachment 296387 [details] [diff] [review] Patch >- BrowserViewSourceOfURL(webNav.currentURI.spec, docCharset, pageCookie); Nit: You also need to remove the declaration and initialization of docCharset. >+ BrowserViewSourceOfURL(webNav.currentURI.spec, pageCookie, aDocument); Bug 331940 added a convenience method that completely replaces this call :-) Don't forget to update the other call, of course! sr=me with these fixed. >+ var utils = window.top.gViewSourceUtils; Unnecessary. Just call gViewSourceUtils directly. >+ <script type="application/x-javascript" src="chrome://global/content/viewSourceUtils.js"/> Nit: This belongs in the generic utility section.
Attachment #296387 - Flags: superreview?(neil)
Attachment #296387 - Flags: superreview+
Attachment #296387 - Flags: review?(neil)
Attachment #296387 - Flags: review+
Transferring r+sr. I don't have a working build environment for suite these days. KaiRo, would you like to test that this still works and drive it in?
Attachment #296387 - Attachment is obsolete: true
Attachment #448545 - Flags: superreview+
Attachment #448545 - Flags: review+
(In reply to comment #174) > I don't have a working build environment for suite these days. KaiRo, would you > like to test that this still works and drive it in? if it's OK with you to wait a few weeks, then possibly. I have a real lot of stuff in my TODO list, and this wouldn't have any significant priority for me.
pushed to comm-central: http://hg.mozilla.org/comm-central/rev/71e60f59c680 Minor typo, fixed locally. Error: window.top.gViewSourceUtils.viewsource is not a function Source file: chrome://navigator/content/navigator.js Line: 1479 Interdiff: --- C:/T1/patches/viewsource/bug8589.2.diff Fri Jun 04 17:39:24 2010 +++ C:/T1/patches/viewsource/bug8589.3.diff Fri Jun 04 18:17:57 2010 @@ -11,7 +11,7 @@ if (url.match(/^view-source:/)) { - BrowserViewSourceOfURL(url.replace(/^view-source:/, ""), null, null); -+ window.top.gViewSourceUtils.viewsource(url.replace(/^view-source:/, ""), ++ window.top.gViewSourceUtils.viewSource(url.replace(/^view-source:/, ""), + null, null); } else { // Check the pressed modifiers: (also see bug 97123) @@ -64,7 +64,7 @@ - "_blank", - "all,dialog=no", - url, charset, pageCookie); -+ window.top.gViewSourceUtils.viewsource(webNav.currentURI.spec, ++ window.top.gViewSourceUtils.viewSource(webNav.currentURI.spec, + pageCookie, aDocument); }
Tested with both internal view source and external view source editor. Thank you simon for your patch! Funny view source error but don't think it's caused by this patch: Error: this.webShell is null Source file: chrome://global/content/viewSourceUtils.js Line: 182
Assignee: nobody → smontagu
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
(In reply to comment #173) >(From update of attachment 296387 [details] [diff] [review]) >>+ var utils = window.top.gViewSourceUtils; >Unnecessary. Just call gViewSourceUtils directly. When I said directly, I meant "not via a useless window.top. prefix" ...
(which as it happens would have avoided having to wrap those lines)
>>(From update of attachment 296387 [details] [diff] [review] [details]) >>>+ var utils = window.top.gViewSourceUtils; >>Unnecessary. Just call gViewSourceUtils directly. > When I said directly, I meant "not via a useless window.top. prefix" ... > (which as it happens would have avoided having to wrap those lines) Fixed. Pushed followup patch to comm-central http://hg.mozilla.org/comm-central/rev/fd4b1728dcae
Product: SeaMonkey → Core Graveyard
Component: View Source → General
Product: Core Graveyard → SeaMonkey
QA Contact: view-source → general
Target Milestone: --- → seamonkey2.1a2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: