See the opening remarks in bug 55583. You try to fuck this one up like you did that one, and I'll slap you! I mean it.

Special reply for submitting in bugzilla Does this mean it is NEW or ... WHAT ...

Strike one. Watch it!

cc to self; interesting game of volleybug.

law@netscape.com is correct -- the original point of bug 55583 is indeed a valid bug that sorely needs to be fixed. I was developing some Java servlets that listened for HTTP POST (so you don't see passwords on the URL bar) and had the generated HTML a bit off, so I thought I'd View Source...wrong! NS4.x and IE indeed show the source, but Mozilla gives me the source of a "405 HTTP method GET not supported by this URL" error. It is incorrectly doing an HTTP GET to fetch the source where it should be displaying the same source it used to render the page.

Not mostfreq - covered by bug 55583. Gerv

*** Bug 64901 has been marked as a duplicate of this bug. ***

*** Bug 66380 has been marked as a duplicate of this bug. ***

*** Bug 70985 has been marked as a duplicate of this bug. ***

*** Bug 75420 has been marked as a duplicate of this bug. ***

nav triage: view source not used by a high percentage of users.

*** Bug 78481 has been marked as a duplicate of this bug. ***

Excuse me, Viswanath, but I and all web developers like me use view-source constantly! Even when I'm not developing...if I see something on a page that is kind of cool...I always do a view-source to see how they did it. This is not minor by any means. I want to see the source of the page I am currently viewing. If it is *any* different, what the hell is the point of view-source then? Jake

let's avoid the flame war if we can, won't help the bug getting resolved... I think it is a double edge sword, to some extent he is correct developers and view sourcers are a relatively small percentage of overall internet users. On the other hand, I would imagine they are a very high percentage of Mozilla users. For a browser to reach its end goal, that is to have as many people using it as possible it would seem to me that the web developer's accepting it as ok has to come first. So while I agree with teh fact that it is a small percentage of the overall internet user base, it is quite possibly the most important 95%. It is hard for me to use a development release to test and submit bugs unless I am using it in a work environment, but if there is a bug preventing my "real" work then I can't use it in the work environment and therefore can't help the open cause. Question really becomes how important is the developer's opinion when it comes to adoption of a "new" web browser.... On a side note, this doesn't even mention the other points, printing, reloading of commerce pages, etc. I would think that the relatively small percentage of people viewing source is directly inverted to the number of people that Print. If they really are related bugs then the whole user base is affected, except for those that neither view source nor print.

renominating for catfood. i agree with hoju.

nav triage team: Bill doesn't have time to do this until at least mozilla1.0. Marking nsCatFood-, nsbeta1-, and adding helpwanted

nav pretriage: moving to mozilla1.0.

*** Bug 84684 has been marked as a duplicate of this bug. ***

*** Bug 85272 has been marked as a duplicate of this bug. ***

When something seems to be simple to fix it's harder to understand when it isn't. Obviously nothing is trivial when you get down to the actual coding but just thinking about the algorithm it's hard to imagine how hard it would be to view the source used to render the current page. Isn't there a copy of the current page somewhere? Either in cache or in memory buffer? If there is then it's the simpliest thing in the world to export that buffer as simple text either to a notepad like viewer or the on-board text viewer currently use. The point is well taken that unless the browser is up to use in a work environment it can't be tested as part of a work environment. Now that AOL has dumped Netscape and will be substituting MSIE as the guts in any future release I thinks it's even more important to please the folks that are willing to go outside the norm to use a non-standard browser. Keep up the good work.

*** Bug 88226 has been marked as a duplicate of this bug. ***

Today I founds myself complaining about how Internet Explorer is such a poor tool for web developers -- how developers needed a browser that would complain when they did something wrong, like a compiler would, instead of quietly trying to do the right thing with your broken code, or hiding the server's real error message from you. My companion's natural question was "what browser would you recommend for a developer?" Of course "Mozilla" left my lips, but I went home hoping to god that this bug gets fixed before my friend takes my advice and discovers it himself. I realize this story is not at all helpful. I just wanted to suggest that this one could become a big advocacy problem.

*** Bug 92177 has been marked as a duplicate of this bug. ***

Until this bug is fixed, IE is the browser I will use to debug all of my web sites. I'd love to give an earful to the person who thinks view source is not used by a lot of people so it shouldn't be fixed. I MAKE the web sites all of those people just look at. One of me makes a bunch of AOL users... I guess I just wont have time to make sure my pages look good in Mozilla.

*** Bug 100288 has been marked as a duplicate of this bug. ***

I also do think this one should have a higher priority since it is one of the crucial features needed for web-developers.

recent changes have allowed the browser to correctly send posts to hosts. that's a good thing. if this were fixed, i'd actually be able to support users of delivered web applications

*** Bug 103150 has been marked as a duplicate of this bug. ***

*** Bug 94729 has been marked as a duplicate of this bug. ***

*** Bug 105664 has been marked as a duplicate of this bug. ***

view-source has been substantially modified, and the means I had envisioned for fixing it is no longer possible. Who should get this bug now? The owner of the view-source Necko protocol handler? Seem like we need support there before we can do anything in the browser (i.e., viewsource.js). Re-assigning to Networking.

I develop web-based app using lots of forms. I depend on view-source to work. The main reason I use Mozilla is because I have an UltraSparc running SuSE Linux. I cannot get Netscape to run. Using IE is not an option, obviously. So do not forget about those of us who are developers and who do not have alternatives. I'd really, really like to see this get fixed eventually.

I'd like to add to the mass of comments asking for something to be done about the view source feature. This bug really needs to be increased in severity from "minor". Some have denigrated it on the grounds that "only geeks use View Source anyway", but MSIE fans denigrate Mozilla itself all over the newsgroups on the grounds that "only geeks use Mozilla" (or anything else other than MSIE, for that matter), so, though some day we all hope Mozilla will expand its user base way beyond the geek community, for now it's stereotyped in that way -- so let's try to make it the *best* "geek browser" it can be! :) For that reason, I'm especially "hot" to get the geek-favorite stuff like View Source and View Page Info working as well as possible. And in the case of View Source, "as well as possible" means that it should always show the source of the page actually being viewed, whether it's a static page or a dynamically generated one, and without ever going back to the server and requesting it again (which can result in the wrong version of the page being showed, as well as more severe problems if the page is a script that produces irreversible action like submitting an order!).

i found today working with harriet that i could get the needed information (what was in the view source) delivered by the cgi via another mechanism. can someone verify that view source has the same html source as a "save as" to the filesystem followed by an editor session using the saved file. if it is, why wouldn't a possible solution to this be to just route the "save as" results to a view window.

cc'ing darin

In respons to castageg@umdnj.edu: I tested this with a build from October 21. When performing a "save as" on a POST generated page, you get prompted (after choosing a filename) that the page contains post data, and if you wish to resend it. If you resend it, you get the correct HTML code. If you do not, you end up with an empty file. I'm not into the source code of Mozilla, but hope this info helps since I hope this bug get fixed. I really miss it when debugging some php scripts...

this sounds like a dupe of bug 55583 *** This bug has been marked as a duplicate of 55583 ***

v