view-source: URLs need overhaul

VERIFIED FIXED in Future

Status

()

enhancement
P3
normal
VERIFIED FIXED
20 years ago
17 years ago

People

(Reporter: warrensomebody, Assigned: vishy)

Tracking

({helpwanted})

Trunk
Future
All
Other
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(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: 19 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.