It would be useful if the View Source page was editable. Some possible uses include: 1) View Source a remote page, do some minor editing and save to local disk. 2) View Source a local page, make minor changes and reload to see changes. I know View means "View" but most file viewers of any file type would also allow you to do limited editing on the file. Related bugs: Bug 63892 that wants to view/edit source AS MODIFIED by scripting Bug 8589 that wants to open source in a helper app Bug 35268 that wants an option to open source in an external app Bug 69329 that wants to open source in a Composer window So far none seems to be an exact dupe, but I'm still looking cause I'm quite sure someone has thought of this before.
Assignee: Matti → doron
Component: Browser-General → ViewSource
QA Contact: imajes-qa → pmac
um. what's wrong with using composer, or copying the source to composer source?
Probably a dupe of bug 63892. Personally I don't think we should add this sort of complexity. It took long enough just to get view source to work from the cache rather than refetching the page!
This is exactly what the "source" mode of Composer already does. There is no reason to duplicate this functionality. Just "Edit Page", switch to source mode, and you're set.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Futhermore, in View Source is already File | Edit Page (Ctrl+E), what opens Composer. I just filled RFE bug 143457 (Edit Page should open Composer on <HTML> Source tab).
Bruce: It's not 63892. Quote from that bug: "I'm thinking that 'View Live Page Source' could display the original page source AS MODIFIED (i.e. comments and whitespace would be preserved as much as possible) by subsequent changes to the DOM, form field information typed, etc." The words "AS MODIFIED" was capitalized by the author of that bug to emphasized that he didn't want the raw View Source, but the interpreted one. However, I am for Comment #5. If that is done, then this is not necessary. Only problem I see with that is that they sometimes do not show the same thing, cause composer changes the source even if I tell it not to "pretty print" the page.
After some further testing I found out that Composer's Edit tab is not really reliable in what I want to accomplish. Here is the experiment I performed: 1) Prefs | Composer | Retain Original Source Formatting. !important; (Theoretically, AFAIK, this should let Composer show the true source) 2) Open a blank page (about:blank) in Navigator. 3) View | Page Source 4) Back to Navigator. File | Edit Page 5) Click the Source tab. Expected: They show exactly the same code. Actual: Composer shows more code than View Source. 6) Make a minor change: press Enter then Backspace. This means no change has been made. 7) Click on another tab, such as Normal, Show All Tags or Preview, it doesn't matter which. 8) Click the Source tab to go back to Composer's source view. Expected: The code is exactly the same as when Composer first opened. Actual: Composer added several spaces, presumably to format the page according to the way Composer deems fit. 9) Repeat the experiment, this time using another page, such as a local HTML file. Make sure to back it up in case you accidentally save the changes Composer makes. Result: Same as previous experiment. Composer's Source tab behaves as though it were just a source viewer of a WYSIWYG editor (which is what it is) rather than a true text editor (which is what I hoped for). Conclusion: Composer is not reliable for those who edit pages as text. The solution proposed in Comment #4 does not address the problem raised by the bug. In other words, it doesn't work. -> Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
If view-source became editable it would be by using the <editor> widget that composer uses. So your argument sort of falls down on the fact that they would act _exactly_ the same.
I suspect it is the WYSIWYG elements of Composer that changes the source, rather than the <editor> widget itself. Composing email as text does not change what I write. Only problem with <editor> is it does not have color coding by tags.
I'm still not sure what the issue is then... We open the source in the source-editor of composer when you select "edit" (per bug 143457) and then _you_ get to choose how you want to edit it. If you want wysiwyg, you deal with the related issues. If you do not, you don't have to. Embedding a dynamically showable text-entry widget into viewsource and then putting in a way to toggle it back and forth and so on is a bad case of reinventing the wheel when we already have the "edit this HTML page" problem solved...
I think you misunderstand my request. All I want is for View Source to behave like Notepad. I'm not asking for some toggle option between a view mode and edit mode. I love the look and feel of View Source - it's clean, readable and fast.
So... do you want the source opened in an editor like Notepad then, instead of using our internal viewsource? View source cannot possibly be editable as it is -- it's just a web page. It would have to be completely redesigned and rewritten somehow to do what you want, if I understand what you want correctly... (you want a built-in HTML editor with syntactic highlighting).
Boris, that's exactly what I want. A built in HTML editor. Syntax highlighting is a plus, but I only thought of it because the current View Source already has it, and people might complain if this feature disappears. A plain, clean, simple editor like Notepad is fine with me. As an analogy with (pardon me) the other browser: they also have a File | Edit which opens the file in FrontPage, which also has a tab at the bottom called HTML. But no one considers View Source to be a duplicate function (even if both are editable). Sometimes, you would just want to view the source, and upon finding something wrong it would be a big help if one could edit it in place instead of firing up a new app. But if this is impossible under the current setup, I apologize. I was just airing out what I thought to be a useful feature, something which people using the other browser are used to having. I just don't understand - why is it impossible to create a text editor in Mozilla? I was under the impression that it was one of the easiest add-ons to make? Sorry for asking.
So.... I'm missing something. What's the point of a built-in editor for view-source? Could it not be farmed out to the OS editor, whatever that is? That is, on Windows we would just open Notepad. It's not hard to put an <editor /> widget in and sticking the source content into it. But you already get that by just opening the page in Editor...
Forgot this in my last comment: What am I missing?
Well, the difference between View Source and Composer is like the difference between FrontPage and Notepad. I don't know how to explain this, but there are times when you need a full-blown editor, and there are times when you just want to tweak what you are currently looking at. I mentioned earlier that View Source is clean, readable and fast. I guess that's what you missed. Most people would open the simplest program that can do the task required, and only open a more complex program when they need to do more complicated tasks. No IE user, for instance, would open FrontPage just to erase a period. I see your point: Composer can already do what I want. You don't see mine.
I always did like the way IE defaulted to viewing source in Notepad. Perhaps make this RFE: allow View Source to open source in user-set editor.
I do see your point. I fail to see why this small light-weight editor needs to be built into Mozilla. See comment 14, first paragraph.
So since you want this, create a patch yourself or help make composer work better. We need to support external editors, thats is the real issue.
> I do see your point. I fail to see why this small light-weight editor needs to > be built into Mozilla. Thanks. Since we agree that it is needed, the question is if it should be built into Mozilla or should it be better to support external editors like Notepad. I don't see why these two should necessarily conflict. Supporting external editors is a good thing whether or not the current View Source is editable. Yes, I also think supporting external editors should have priority over this one. But it would be also good if the feature was also supported internally. I can only think of one reason: it is one of those things that you realize you need when you've had it for a long time and then suddenly it's gone. A (bad) analogy: IE users would never know they need tabs until they try Mozilla for a few weeks. Like you are staring at the source and you feel helpless cause you can't edit it and you end up firing up Composer which takes up so much memory and takes too long to load, just to satisfy that tiny urge to edit. Yes, firing up external editors like Notepad would solve this. But personally I won't feel a need to open up Notepad if the current view source is already editable. I would only launch external editors for more specialized needs, like if I need a more powerful search-and-replace function. In fact, most people (especially IE converts) would feel that the ability to edit the source as being viewed is such a basic functionality that it is surprising that Mozilla doesn't have it. You may question why it is basic: if you've been using IE for sometime, you would consider it basic. (hard for me to explain this feeling) Bottom line: For such a basic feature, it is surprising that Mozilla doesn't have it. Launching external programs is good, but that should only be if you need specialized functionality found in those programs.
Er, your comparison to IE doesn't make sense to me. Because IE doesn't have an editor built in - it just uses Notepad, or Word, or Frontpage Express, or whatever you've told it to. So having Mozilla open the source in the user's text viewer of choice (including an option for the present source viewer) would solve the problem to IE parity. And avoid introducing an exciting new bugsource^Wfeature to Mozilla ...
<shrug> Confirming rfe, but I still fail to see the point over having a crappy internal editor of our own instead of using the user's editor of choice... (and yes, our internal editor is nowhere close to being usable for text editing, imo).
Status: UNCONFIRMED → NEW
Ever confirmed: true
If we really want external editors, then I guess that should be it. :( I just thought that Mozilla should do this herself.
I agree with Bamm, and I feel this is really a matter of opinion. I guarantee, though, that even if you can't see the logic in this, you will be happy it was implemented some time when you take advantage of it. View-Source has a lot of things over Composer's text editor, such as syntax coloring, and also people might not realize how to edit in composer without messing up their page. Besides, composer takes a while to load for something simple as Bamm said. In my opinion, if this is to be done the best way, it is to somehow share code between composer's plain-text editor and view-source (without having to load all of composer for view-source). I don't know much about this, but if the Editor widget does that, then allowing for syntax coloring (based on syntax color listing files that are addable or editable), internal or external line numbers (bug 15364), etc, would be a way to save time through code-reuse, and solve inconsistancies between composer and view-source. As for the external editor, notepad and wordpad really stink for editing any kind of code. This would also depend on some other operating system to have a text-editor. That is why I want view source to stay available even with a helper application (bug 145640).
See bug 145652.
Notepad and Wordpad are both _much_ higher quality editors than what we have in Mozilla. They do not lose content and they do not suddenly send your cursor off to lala-land. *** This bug has been marked as a duplicate of 8589 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
This is not a duplicate. Besides, wordpad and notepad both stink and probably could have an equivalent application written in two days.
I was voting to make View Source editable, not reporting a new bug.
I don't think this is a duplicate. This bug is a request for the internal View Source to be editable, whether or not there is an option to view it in an external app. If this is not desired, then feel free to mark this as a WONTFIX instead. -> Reopening.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
-> Default Owner
Status: REOPENED → NEW
Either you fix it or this is a wontfix.
Assignee: doron → bamm
I wasn't able to get this to work in firefox, but I thought it might be important to note that any webpage can be edited, the feature is simply disabled (http://www.squarefree.com/bookmarklets/misc.html#edit_page). Unfortunately view source opens in a new window, but if it were to open in a tab, that bookmarklet might work for this situation, and if it does, it would make a patch for this bug very simple.
Sorry to spam. I just figured out how to view source in tabs, but yeah, the bookmarklet kinda works. The only problem is, when you try to save the source page it saves the original, not the one you edited. So, in order to save the changes you'd have to open up an external app, which I guess doesn't get us anywhere, it just means that when you copy and paste the html, you'd be copying the edited html and then just saving, and not copying the unedited html, editing, and then saving. It's not much, but I would think it makes implementing this rfe simpler.
Assignee: bammzilla → mrbkap
QA Contact: pmac → doronr
Assignee: mrbkap → nobody
QA Contact: doronr → view-source
SeaMonkey trunk is now using toolkit viewsource.
Component: View Source → View Source
Product: SeaMonkey → Toolkit
QA Contact: view-source → view.source
You need to log in before you can comment on or make changes to this bug.