Closed
Bug 15372
Opened 25 years ago
Closed 24 years ago
view-source: URLs need overhaul
Categories
(Core :: Networking, enhancement, P3)
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".
"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?
Reporter | ||
Comment 2•25 years ago
|
||
Perhaps we don't need this, but if we do, we should take this RFE into
consideration.
Reporter | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M20
Reporter | ||
Comment 3•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
warren, do you know what the latest is on our view source front?
Reporter | ||
Comment 6•25 years ago
|
||
Cc'ing Brendan to get his opinion on whether this enhance is worthy of any
further consideration.
Comment 7•25 years ago
|
||
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
Reporter | ||
Comment 10•24 years ago
|
||
I think this is very low priority.
Assignee: valeski → nobody
Status: ASSIGNED → NEW
Keywords: nsbeta2 → helpwanted
Target Milestone: M20 → Future
Comment 11•24 years ago
|
||
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].
Comment 12•24 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [need info] → [nsbeta2-]
Comment 13•24 years ago
|
||
I'm assigning this to myself so I can evaluate this in a post-6.5 timeframe.
Assignee: nobody → don
Assignee | ||
Comment 14•24 years ago
|
||
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
Vishy
Assignee: don → vishy
Comment 15•24 years ago
|
||
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?)
Comment 16•24 years ago
|
||
*** Bug 56898 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
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 ...
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
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 ...
Comment 20•24 years ago
|
||
Now in - see bug 66334
Comment 21•24 years ago
|
||
So this is Fixed in bug 66334 right? Any reason to keep this bug open?
Comment 22•24 years ago
|
||
Resolving ad FIXED.
e.g., view-source:http://www.mozilla.org works.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 23•24 years ago
|
||
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?
Comment 24•24 years ago
|
||
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
Comment 25•24 years ago
|
||
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.
Comment 26•22 years ago
|
||
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.
Description
•