Closed Bug 15372 Opened 25 years ago Closed 24 years ago

view-source: URLs need overhaul

Categories

(Core :: Networking, enhancement, P3)

All
Other
enhancement

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: warrensomebody, Assigned: vishy)

References

()

Details

(Keywords: helpwanted, Whiteboard: [nsbeta2-])

It looks like the browser supports some sort of view-source: URL (see bug 3118) that doesn't allow you to specify a protocol (besides http, implicitly). We should fix that to make it take a full spec: view-source:http://www.disney.com perhaps defaulting to http if one isn't supplied. I'm sure this whole view-source thing is done in an ad-hoc fashion now in the webshell, and perhaps it should be generalized to allow you to supply the window name too (the third leg of the URL dispatching tripod). Maybe: load:http://www.disney.com!/command=view-source&window=fred (borrowing the !/ syntax from jar: URLs -- or maybe it should just be !). If command isn't specified, it defaults to "load" (or "view" or whatever it is), and if window isn't specified, it defaults to "_self".
Blocks: 13449
"the browser" mentioned in 3118 was Navigator. Mozilla doesn't seem to know what to do with "view-source:www.disney.com" (Necko generates a "unknown protocol" error of some sort, I think). Are we going to do view-source: pseudo-protocol at all in 5.0?
Perhaps we don't need this, but if we do, we should take this RFE into consideration.
Status: NEW → ASSIGNED
Target Milestone: M20
I take this as a possible part of the URL dispatching work.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
warren, do you know what the latest is on our view source front?
Cc'ing Brendan to get his opinion on whether this enhance is worthy of any further consideration.
view-source:<real-url-here> remains a popular netscape "content developer" feature. I think we should do it, or at least scope the work in this bug, so we can prove to ourselves that all our newfangled modularity makes it easy to add this feature. /be
view source isn't a command anymore. Basically the view-source: on the URL bar should be pulled out by navigator.xul because it is the one that actually is suppose to create a new view source window. Webshell or docshell knows nothing about dispatching view-source requests. Esentially a docShell can be in one of two modes. View Source Mode or normal rendering mode. If you do view source with viewer you will note the window that comes up will allow you to type any URL in it and have it navigate to that URL while in view source mode. We have talked about doing this to Apprunner too. Simply adding an URL bar to the view source window that comes up would allow more general navigation and just picking up the source. But as for the act of typing "view- source:http://www.aol.com" into the URL bar of Navigator.... It is up to Navigator to recognize the view-source string and to do the load on it's own.
I think view-source: should be in the product for backward compatibility reasons. Please consider including it for beta2.
Keywords: nsbeta2
I think this is very low priority.
Assignee: valeski → nobody
Status: ASSIGNED → NEW
Keywords: nsbeta2helpwanted
Target Milestone: M20 → Future
Ok, I was just in #mozillazine and used view-source: to help triage a bug. This is an important feature, and I'm not certain there's any other way to expose it. I'm marking need info, because I might be able to do the work if I understood what needs to be done. Generally, the view>source menuitem views the source of a page after rendering (which means that many <script> tags should be gone replaced by their output), the current view>source menuitem results in a window w/o any input objects, you can't specify a location. Composer does so much mangling that it isn't even a reasonable consideration [In nc4 it was].
Keywords: 4xp, nsbeta2
Whiteboard: [need info]
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [need info] → [nsbeta2-]
I'm assigning this to myself so I can evaluate this in a post-6.5 timeframe.
Assignee: nobody → don
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
also note bug 56898 for its similarities; is this a dup of 56898 or vice versa? In addition, Mozilla has, from time to time, dumped me into some sort of view-source mode where I load all html pages as raw text (seing the html code on each website I visit). (is this a separate bug?)
*** Bug 56898 has been marked as a duplicate of this bug. ***
I've frequently used a View-Source URL in demo/class type pages where you can use a view-source link which pops a new window with the source of the current page, right off the document. With mozilla this isn't possible, except for maybe doing some serious DOM work and document.writing it to a window ... wouldn't it be nice to just be able to use the URL? adding myself on a cc:, so i can listen in ...
Proposing for Mozilla0.9 since 1) this is a widely used developer feature in Netscape Navigator 4.x and IE and 2) there isn't currently any other way to access this. It's very convenient to be able to get the source of a js file with view-source, for example. Also see bug 74855 about using JavaScript to trigger view-source. (I've also seen bookmarklets for this.)
Keywords: mozilla0.9
again, i second that. just yesterday, i was doing yet another demo of code and wanted to have a link for view-source ..... can't do it in NS6/Mozilla ...
Now in - see bug 66334
So this is Fixed in bug 66334 right? Any reason to keep this bug open?
Resolving ad FIXED. e.g., view-source:http://www.mozilla.org works.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
But view-source:http://www.mozilla.org/persistent-style.css doesn't. So you still can't view JavaScript .js files, CSS files without saving them. These and other text-like files Mozilla can't view. Should that be a new bug? Are the hooks now in place for them. Also, why doesn't view-source: open in new window?
Interesting. When you browse via a URL to a css file, it displays the source as a text file. When you do a view-source:URL on a css file it prompts you to download. When you browse via a URL to a js file, it prompts you to save the source. When you do a view source:URL on a js file via a URL it also prompts you to save the source. However, actual HTML href links do now display html source as i'd like to see. It'd be nice if these things still worked tho. CSS files and JS files are two of the main reasons to have this at all. Why bother with doing it at all if these two aren't implemented? You can view HTML source from the view source or context menus anyways. Can't commented on whether it should be a seperate bug, but my original feeling for wanting this included was primarily for CSS and JS files, not html source. Good catch tpowell. :rob
Yes, the ability to view javascript and css file source was the main reason I wanted this fixed. view-source: is also 4xp and supported nicely in IE. I logged bug 77337 about all the different text/whatever mimetypes not being supported in view source.
VERIFIED: new problems to new bugs please.
Blocks: 130089
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.