Last Comment Bug 55583 - view-source should show original page source (use cached source)
: view-source should show original page source (use cached source)
Status: VERIFIED FIXED
[Hixie-P1] (HTTP) blocked by 40867 [b...
: arch, dataloss, helpwanted, highrisk
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: P2 major with 84 votes (vote)
: Future
Assigned To: rpotts (gone)
: Adam Lock
:
Mentors:
http://ntiaotiant2.ntia.doc.gov/test/...
: 56575 56861 57749 57846 58703 59642 61325 62746 63589 63598 64100 65601 65788 66993 67534 68588 71251 74834 77863 78086 80301 80989 81403 81531 81913 82489 83122 84393 85398 91456 95149 99449 99971 100529 100728 100939 102499 104607 105554 105683 106230 107948 110489 110717 110827 110864 110959 111466 113304 115059 116070 117197 117391 117634 118536 118562 119008 120804 121436 123166 124509 125095 125866 126521 127644 128031 128166 128298 128529 128803 131582 131996 132215 132606 132663 132740 133636 134024 134272 134661 137204 137397 137479 138534 139754 144794 148072 162211 (view as bug list)
Depends on: 40867 90722 99107
Blocks: 79518 86835 advocacybugs 98995
  Show dependency treegraph
 
Reported: 2000-10-06 16:11 PDT by Bill Law
Modified: 2014-04-26 03:32 PDT (History)
173 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
etheniel homepage bug (112.93 KB, image/jpeg)
2002-04-05 09:28 PST, Robert Jirik
no flags Details

Description Bill Law 2000-10-06 16:11:14 PDT
viewsource.js loads urls in the view-source window but doesn't provide form post
data.  This won't work on pages that result from form post submissions.
Comment 1 Ben Bucksch (:BenB) 2000-10-09 11:46:13 PDT
Won't this be fixed by bug 40867 anyway?
Comment 2 Bill Law 2000-10-09 13:17:18 PDT
Depends on if/how that bug is fixed.  I wouldn't suggest being too optimistic
and closing this one as a dup, it that's what you're thinking.
Comment 3 sairuh (rarely reading bugmail) 2000-10-16 14:34:59 PDT
*** Bug 56861 has been marked as a duplicate of this bug. ***
Comment 4 sairuh (rarely reading bugmail) 2000-10-16 14:47:58 PDT
*** Bug 56575 has been marked as a duplicate of this bug. ***
Comment 5 sairuh (rarely reading bugmail) 2000-10-24 15:11:10 PDT
*** Bug 57846 has been marked as a duplicate of this bug. ***
Comment 6 timeless 2000-10-26 11:03:07 PDT
reminder to self: have patched DumpDOM.js that allows retrieval of 
live document source.

all: any ideas how this could be used by view source?
Comment 7 Henrik Gemal 2000-10-31 23:34:23 PST
*** Bug 58703 has been marked as a duplicate of this bug. ***
Comment 8 marshall 2000-11-17 13:43:00 PST
An idiosyncracy of a URL I experience this on is not just that the page is
dynamically generated from a post, but that the form tag has no action
attribute, so that submitting the form goes back to the same URL, which then
returns a different page. But view source shows the first page's source.
(The URL I experienced this on is on an internal development site that's
only intermittently available outside of our network, if at all.  If you
want to see it, I can probably make an instance of it available.)
Comment 9 Jesse Ruderman 2000-11-19 02:12:06 PST
Marking as depending on bug 40867.
Comment 10 Jesse Ruderman 2000-11-19 03:21:47 PST
*** Bug 59642 has been marked as a duplicate of this bug. ***
Comment 11 timeless 2000-11-21 20:24:36 PST
We don't need that. what we need is a decision about how to expose two 
different view-source methods. Viewing live source (which I have implemented) 
and the current view page source. I think that I can safely replace the 
view-source menu with my view live source, however my current implementation 
has one major problem:

I am using data:text/plain,<source> and I don't know how to embed newlines so 
as a result the entire source is on a single line.  I'm told data is in base64, 
so if you can explain how to encode newlines I can implement this fix.

mpt: I need a cost benefit analysis of replacing the current view source menu 
backend with code that results in the current page's source.

One important note to all: my backend asks the DOM and therefore the source is 
based on how the dom thinks about it, not how it was written
<html><body><p>hi</p></body></html> is given a few newlines and indentation [by 
me] because I can and because there is no way that I know of to ascertain the 
original format (in all cases, sure we could use the current technique but that 
fails miserably for javascript generated pages).

Essentially my view-source implementation is related to netscape4's 
view-source:wysiwyg://1/<url>
Comment 12 Ben Bucksch (:BenB) 2000-11-21 21:37:27 PST
I think, the current page source is nice, but is no substitution for the normal
view source. The latter is e.g. useful to track bugs in the page, and the former
could hide evil content (e.g. an evil script which at the end overrides its own
source with something harmless).
Comment 13 Matthew Paul Thomas 2000-11-22 18:09:28 PST
Timeless, I think what you are implementing with original vs. DOM source is cool, 
but completely unrelated to this bug, and the dependency on bug 40867 is entirely 
appropriate.

It is quite possible that a form submission (like any other page) could contain 
stuff which manipulates the DOM, but a user should always be able to see the 
original source of the page as well.
Comment 14 timeless 2000-11-27 21:47:59 PST
Ok ->Networking:Cache.
Comment 15 Luis Villa 2000-11-28 12:19:51 PST
*** Bug 61325 has been marked as a duplicate of this bug. ***
Comment 16 Jesse Ruderman 2000-12-06 01:10:29 PST
Viewing generated source is now bug 60426.
Comment 17 pohl 2000-12-07 08:30:54 PST
Adding CC to self

I have been building and using mozilla from the cvs trunk, and have been
annoyed by this particular bug.  I develop servlets for my employer, and
would like to be able to view what comes back from MyServlet.doPost() in
mozilla.  I always end up seeing what is generated by MyServlet.doGet() instead,
making me open Netscape 4.xx -- yuck.
Comment 18 timeless 2000-12-13 08:35:17 PST
*** Bug 62746 has been marked as a duplicate of this bug. ***
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2000-12-13 09:10:13 PST
*** Bug 57749 has been marked as a duplicate of this bug. ***
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2000-12-13 09:11:04 PST
*** Bug 62746 has been marked as a duplicate of this bug. ***
Comment 21 Robert Kaiser 2000-12-13 13:47:32 PST
hmm, I think this should get into mostfreq list when looking at all that dupes...
Comment 22 hirata masakazu 2000-12-22 04:41:14 PST
*** Bug 63589 has been marked as a duplicate of this bug. ***
Comment 23 hirata masakazu 2000-12-22 08:31:45 PST
*** Bug 63598 has been marked as a duplicate of this bug. ***
Comment 24 Ben Bucksch (:BenB) 2001-01-01 05:29:21 PST
It is not just POST which fails, also some GETs, and possibly other cases. See
the recent discussion on bug 6119, which is the predecessor of this bug.

Upping severity to major, adjusting summary.
Comment 25 Deven Corzine 2001-01-01 09:13:29 PST
I would suggest a more accurate summary of "view-source should show the original
source" since pulling from the cache is sometimes what causes the results to be
wrong!  (See comments under bug 6119 for details.)
Comment 26 timeless 2001-01-01 09:43:09 PST
And the fact that we don't even cache all objects.  Maybe "history objects" 
should get nscomptrs to the cache'd documents.  As such, necko wouldn't be able 
to destroy them from cache until the window containing them is closed.

There's a risk here, I have testcases that require ~900MB of VM to load, if 
someone happened to load a few unique cases like these they'll kill their 
system [windows doesn't like more than 4GB per swap file, and well, it's hard 
to make lots of swap files].

Can we do some analysis of the competition and find out how much they history 
cache? (I expect they don't history cache more than 10mb of data) And of 
course, do they history cache images (all, up to what size, ..., only 
generated)?

Probably the best way to test this, as mentioned in 6119 is to browse to a 
bunch of sites and then clear cache [n4 has a memory cache which is set to 2mb 
on my machine, i wonder if that's the history cache]. Iterate back through your 
pages and record what survived.
Comment 27 Deven Corzine 2001-01-01 10:03:53 PST
This would be better discussed under bug 40867, where the architectural issues
have been raised, and would fix that bug, this one, and several others.  That
said, bug 56346 is worth checking out, because it has a quote from RFC 2616
describing how and why history mechanisms should be be different from caches.

Now, I don't know if "history objects" should get nscomptrs (which I'm assuming
is a reference-counted pointer?), but it seems clear that they should have a
unique reference of some sort.  However, nothing precludes that unique reference
from representing history data stored on disk; it's not strictly necessary to
store it in VM.  And if there's no hope of storing the page in either memory or
on disk, there could be a dialog box a la NN4's warning about re-posting form
data.  At least the user would know when the original data had been lost. 
(Maybe it should require confirmation before discarding the old data?  Maybe it
should never discard data for the currently-viewed page of any open window?)

As for your 900MB testcase, is that mostly the source or the constructed DOM? 
If it's mostly the DOM, would it be feasible to save the source, reconstruct the
DOM when returning to the page, then (somehow) apply any changes that were made
to the DOM previously?  (By the way, what sort of testcase uses such an enormous
amount of VM to load?)

Regarding the competition, shouldn't we aim for doing the "right" thing, whether
or not the competition does?  (Presuming, of course, that the "right" thing will
inherently be at least as good as whatever the competition does...)
Comment 28 Ben Bucksch (:BenB) 2001-01-01 10:11:30 PST
Changing summary based on Deven's suggestion.

timeless, good point. I remember somebody saying that MSIE is extremely fast
rendering the last few (3 or 4, IIRC) pages. He claimed that MSIE cached the DOM.

Deven, re your contribution questions: It is OK, even encouraged, to claim so,
if you work on a bug, so no work is duplicated. If you are not sure, if you have
time or competence, just start playing with. If you get stuck somewhere, you
could post what you find out - it might help the guy who then does the rest to
fix the bug. Because of the importance of this bug, I suggest not to assign it
to you unless you can fix it.
Comment 29 Ben Bucksch (:BenB) 2001-01-01 10:15:42 PST
> I remember somebody saying

BTW: It was not a Mozilla developer, so take that info with caution.

> which I'm assuming is a reference-counted pointer?

Yes.
Comment 30 timeless 2001-01-01 10:22:21 PST
The problem is I'm not sure anyone has a good idea of what the right thing is.  

My testcase was actually graphics, but I know others who have purely huge html 
files, and if all of my graphics were inline svg's ...  

wrt abandoning the source, if you had a sparse page 
<html>%20x10000000<head>%20x10000000<title>%20x10000000Something%20x10000000</t
itle> ... where %20x10000000 means 10000000 spaces. then it would probably be 
reasonable for us to store a copy of the document's meaningful code instead of 
its actual code [yes someone might want to count 10 million spaces, but um, the 
average view source user probably doesn't need more than 2 spaces between real 
code].  However i'm not really sure how to describe what we are storing and how 
often these cases occur.  I think cgi POST/GETs are probably <10k and 
presumably there are only a few cgi generated images.

[a reminder that some web authors might be trying to "hide" evil code in their 
source, or even to use a buffer overrun. other times people try to protect 
their code by obfuscating it] i use code here to mean html markup code and 
include inline scripts.

I need to find netscape2 and netscape3.
Comment 31 Jesse Ruderman 2001-01-01 15:05:30 PST
updating summary
Comment 32 Deven Corzine 2001-01-01 16:32:10 PST
I think a lot of people have a good idea of what the right thing is, which is
why there's so many duplicate bugs reported of behavior that isn't quite right!
On the other hand, I guess it's ambiguous enough to require some debate...

I guess I'm something of a purist when it comes to something like "view
source".  I really do want to see *exactly* what the browser received, even if
that source contained 10,000,000 spaces that were semantically equivalent to
one.  While it seems unexpected to see so many spaces, let's imagine that it
really is happening, perhaps because of a dynamic content engine malfunctioning
(or at least, being inefficient).  If I (as the user) have waited for megabytes
of information to come over the wire, and then "view source" shows me one page
of source, I'm going to think there's something fishy going on.  If I see the
exact source, I may be surprised at such a plethora of spaces, but I'll
immediately look to the content being generated and NOT suspect the browser of
misleading me.  Those 10,000,000 spaces may mean nothing to the browser, but
they might be significant to me, or at least it would be confusing to have them
elided without warning...  (Now, having an *option* to elide meaningless data
would be valuable, for users who are wanting and expecting such a feature...)

Considering both the RFC quote and common sense, it seems most "right" to have
any "history" functions (back/forward, view-source, save-as, etc.) to operate
with exactly the same data as before, regardless of the size or state of the
cache, and regardless of what content changes may have occurred on the server. 
And yes, logically this even applies to image data, despite the size.  Nothing
stops us from writing the information out to disk until it's needed, since we
can be sure that we'll be reloading the original data from disk.  (Also, we
could compress the data with zlib, to save disk or memory space, at a CPU cost.)

The obvious danger is that saving too much leads to "bloat".  On the other hand,
when there's enough memory to do it, it is a big performance win.  The tradeoffs
involved should probably be left up to the user, don't you think?  (What do you
think of the idea of a separated cache manager as I suggested in bug 40867?)
Comment 33 Ben Bucksch (:BenB) 2001-01-01 17:22:23 PST
I agree with Deven. I want to see *exactly* what the server sent, without headers.

I don't know how an author could "hide" code, given that scrollbars will appear.
I can always use an external reformatter, if the code has been obfuscated.
Comment 34 Scott Gifford (old account) 2001-01-01 19:17:36 PST
Adding self to CC, and agreeing vigorously with Deven.
Comment 35 Bill Law 2001-01-02 12:00:21 PST
Darn it.  I opened this bug for a very specific reason.  The view source code
does not handle URLs with form post data.

What the hell happened?
Comment 36 Ben Bucksch (:BenB) 2001-01-02 12:05:36 PST
law, your call, how we track the other problems. But, as pointed out, there
*are* remaining problems apart from POST. And they are just as urgent as POST.
Comment 37 timeless 2001-01-02 12:43:56 PST
law made his call.
Comment 38 Deven Corzine 2001-01-03 11:20:01 PST
Sorry, law.  I asked for bug 6119 to be reopened because it didn't seem to be
completely fixed.  Everyone kept directing the discussion over to this bug
because it was a "successor" to 6119.  I didn't mean for this bug to lose its
focus, but nobody seemed to want 6119 reopened.

For what it's worth, I do believe that properly solving the issues raised in bug
40867 will fix the POST problem as well as the remaining issues from 6119...
Comment 39 Bill Law 2001-01-03 14:13:36 PST
40867 might well need to be fixed and doing so might make it easy to fix some of
the more subtle view-source quirks.  But it is distinct from the problem I
raised with this bug initially (and with my new bug, whose number must remain
top secret :-).

The code in viewsource.js has to step up to deal with form post data in some
respect, otherwise, you are unlikely to be able to reliable fetch the data from
anywhere.  The reason is that the URL by itself is insufficient to uniquely
identify the source.  For example, you might have two windows that show distinct
form submission results from the same URL.

So I think this bug needs to be fixed independent of other work on some
pseudo-cache that holds source for current content.  When such a facility is
online, viewsource.js can be modified to pass whatever is necessary to get the
proper source from that facility.

I really want a separate bug because then we might have a chance to fix the
problem for the majority of cases (i.e., the source is actually in the cache)
even if we don't fix 40867.  I wouldn't bet money on 40867 getting fixed by
Mozilla 1.0.
Comment 40 Ben Bucksch (:BenB) 2001-01-03 14:24:25 PST
> So I think this bug needs to be fixed independent of other work on some
> pseudo-cache that holds source for current content.

I see. So, it was actually wrong to widen the scope of this bug. Sorry. I should
have reopened the other one. Too late.

> I wouldn't bet money on 40867 getting fixed by Mozilla 1.0.

IMO, this bug is a Mozilla 1.0 must-fix.
Comment 41 pohl 2001-01-03 15:06:56 PST
> > I wouldn't bet money on 40867 getting fixed by Mozilla 1.0.
>
> IMO, this bug is a Mozilla 1.0 must-fix.

I feel moved to agree with this comment. I think Mozilla-the-platform
needs happy developers who can use Mozilla-the-browser to view the
output of their cgi/php/servlet pages.  Or have the platform ambitions
waned a bit?

Comment 42 Deven Corzine 2001-01-03 20:03:47 PST
> > I wouldn't bet money on 40867 getting fixed by Mozilla 1.0.
>
> IMO, this bug is a Mozilla 1.0 must-fix.

Just to be clear, does "this bug" refer to bug 55583 or bug 40867?
Comment 43 Ben Bucksch (:BenB) 2001-01-03 21:05:37 PST
both.
Comment 44 Deven Corzine 2001-01-03 21:11:50 PST
Okay.  I've already mentioned under bug 40867 that I'm willing to work on that
bug unless and until someone else comes along to work on it that can make a
stronger commitment to delivering a fix.  (I may not deliver anything, but I'd
rather work on it anyway, if nobody else is ready to work on it yet...)
Comment 45 Stephan Niemz 2001-01-10 07:40:44 PST
*** Bug 64901 has been marked as a duplicate of this bug. ***
Comment 46 Frank Weng 2001-01-10 07:55:48 PST
add myself to cc
Comment 47 hirata masakazu 2001-01-16 10:14:13 PST
*** Bug 65601 has been marked as a duplicate of this bug. ***
Comment 48 Keyser Sose 2001-01-17 17:22:32 PST
*** Bug 65788 has been marked as a duplicate of this bug. ***
Comment 49 Judson Valeski 2001-01-23 13:18:48 PST
this might be fixed if 66334 gets fixed.
Comment 50 Stephen Walker 2001-01-29 18:34:56 PST
*** Bug 66993 has been marked as a duplicate of this bug. ***
Comment 51 Jesse Ruderman 2001-02-03 15:59:05 PST
*** Bug 67534 has been marked as a duplicate of this bug. ***
Comment 52 Fabian Guisset 2001-02-12 08:07:07 PST
*** Bug 68588 has been marked as a duplicate of this bug. ***
Comment 53 neeti 2001-03-05 09:03:58 PST
Cache bugs to Gordon
Comment 54 Oliver Klee 2001-03-07 17:56:35 PST
*** Bug 71251 has been marked as a duplicate of this bug. ***
Comment 55 James Paige 2001-04-23 10:34:31 PDT
*adding self to CC list* If view-source doesnt show me EXACTLY byte-for-byte
what it downloaded from the server (WITHOUT re-requesting it) then view source
is utterly useless to me :(
Comment 56 Deven Corzine 2001-04-25 10:38:55 PDT
Reminder: there's a lot of relevant discussion under bug 56346 and bug 40867...
Comment 57 Wiggins 2001-04-26 13:52:44 PDT
Must say the discussion between Bug 56346, Bug 55583, and Bug 40876 if nothing
else is impressive. As a web app developer I would have to agree with Deven, in
that this bug needs to be fixed in the right way rather than the easy/fast way.
I also noticed that in all of the discussion of Get/Post on this particular bug
as well as the other 2 mentioned above, and with the discussion of XML/XUL/etc.
on the history of Bug 40876, no one mentioned Cookies.

For instance I am developing a series of applications that have many functions
in one script (aka, the same url) but that also check/set cookies to vary the
content of those pages (I am not stating that is impressive, actually I am
thinking it is very common), which also means it adds another level of
complexity when it comes to the idea of storing the page in the cache. It is one
thing to store the base url, the POST/GET parts, the browser window, but are you
also going to store the state of every one of the cookies that is available to
that series of domains??? I think Deven was initially correct in stating that
while storing the page(s) in memory may be memory intense, it is overally
complex to store the necessary attributes in either cache (or regenerating from
DOM, see other bug discussions (which I think was nixed)) and will eventually be
less than perfect when re-representing the page to the end user, be they
browsing, purchasing, developing, etc.

Thanks to the developers, and everyone that has put their time and hearts into
it......
Comment 58 Henrik Gemal 2001-04-27 02:53:53 PDT
*** Bug 77863 has been marked as a duplicate of this bug. ***
Comment 59 rbs 2001-04-28 23:20:31 PDT
*** Bug 78086 has been marked as a duplicate of this bug. ***
Comment 60 Gagan 2001-05-02 17:16:12 PDT
this would require the fix for bug 40867 and some view-source magic which I
think chak owns... So once the former is fixed this needs to use the
cachedescriptor to fetch the doc again (from the cache) and it should work fine. 
Comment 61 Chak Nanga 2001-05-07 15:33:24 PDT
Cc:ing Boris for his insight since he's been working on a lot of viewsource: 
related issues.
Comment 62 Anthony Evans 2001-05-08 16:23:16 PDT
In Mozilla .9, "view frame source" makes another trip to the webserver (I record
it in a debug log that I keep on the server), only without the POST data
(regardless of cache settings).  Obviously, this happens in NN6.01 too.

Since I am using POST and a hidden frame for proprietary purposes, this can be
quite maddening (ie: when I unhide the frame and view the source).

If you need a test case, let me know and I'll hammer one together, but it looks
to me like you already have plenty of information on this issue.

I confess I speed-read this bug's history, so forgive me if I've gotten the
wrong idea:  It appears to me that under some circumstances, making another trip
to the server, indeed, another POST to the server, is being considered as a
potential "fix" (that is, what if the page contents are not in the cache or the
cache is turned off?).  This really alarms me.

POSTs, in some applications can be associated with database transactions or
content that is changing on the server.  There is no guarantee that two
identical posts will return the same results.

I really would like to see what the webserver sent me, without modification and
without making another trip to the webserver, regardless of the state of my
cache settings when I view source.
Comment 63 John Keiser (jkeiser) 2001-05-08 20:21:38 PDT
This cry comes out from many developers.  The problem is, for non-developers, 
not hogging up all the memory is most likely more important than having a 
pristine copy of everything in the browser's history.

So here are the two things that I think need to be done:
1. Make a pref like "Keep source to all history pages" (and maybe a separate 
one "Keep all images in history").  When this is turned on, have History hold 
hard references to all pages, frames, and possibly images in the cache.
2. Make it so that pages with hard references can be moved to disk so that at 
least RAM is not completely consumed when this happens.
Comment 64 Robert Kaiser 2001-05-09 09:21:22 PDT
John, IMHO we should never re-fetch the (currently shown) page from the web
again if the user does "view source", save or print. Also the "normal" user
would suffer from re-POSTing if the page is a buying confirmation to some
shopping trip on the web - and he might want to save or print this page. A
developer (I think the "standard" user won't ever need "view source") would like
to view the code a different developer used to show him the perfect design of
this confirmation page.
If we do a POST again here, anyone who clicks view source, save or print will
risk buying a second item of something he only wants once.
As we have the fuctionality lying around, we should simply use it, I think. We
don't need to do that for every page in history - just for the one currently viewed.

A second case where we would need this is when a second POST might show
completely different code (e.g. you're deleting a guestbook entry - the second
POST will tell you the entry doesn't exist while the first told you that the
delete was successful) - you'd never see the source you want to see in those cases!
Comment 65 John Keiser (jkeiser) 2001-05-09 09:46:46 PDT
Oh yes, I totally agree.  In all circumstances the current page should hold a 
hard reference to the cached page.

I was under the impression that the previous poster was talking about all POSTs 
for all time, but now, re-reading it, I am not so sure.

Anyway, even if we start holding hard references to the current page, IMHO we 
still need to be able to move these pages and images to disk without 
invalidating the hard reference.
Comment 66 Judson Valeski 2001-05-10 09:03:20 PDT
back to gordon. all chak did was change view-source from being a "mode" to a 
"protocol handler".
Comment 67 gordon 2001-05-10 11:27:07 PDT
So why should I get this bug?  Gagan, can you find the owner for view-source?
Comment 68 Simon Fraser 2001-05-10 12:34:21 PDT
law@netscape.com is the owner for view source (or someone in xpapps). Can one of 
you necko folks say what special cache flags are required to get the correct 
source?
Comment 69 Gagan 2001-05-10 15:41:22 PDT
in that case ->law and law: check with darin on the cache flags to use
Comment 70 Boris Zbarsky [:bz] (still a bit busy) 2001-05-15 11:41:22 PDT
*** Bug 80989 has been marked as a duplicate of this bug. ***
Comment 71 rbs 2001-05-21 03:31:29 PDT
*** Bug 81913 has been marked as a duplicate of this bug. ***
Comment 72 Sean Richardson 2001-05-21 13:28:50 PDT
Adding "(use cached source)" to summary to make this bug more re-findable.
Comment 73 Sean Richardson 2001-05-21 13:33:33 PDT
*** Bug 81403 has been marked as a duplicate of this bug. ***
Comment 74 Paul Chen 2001-05-21 16:19:11 PDT
nav triage team:

Not a beta stopper, marking nsbeta1-. The helpwanted keyword is still there. ;-)
Comment 75 Georg Maaß 2001-05-22 05:16:31 PDT
Mozilla 0.9 chances a POST to a GET, when the source view menu item is seleced
on a page received via POST. This is awfull, because it truncates the POST
paramaters from the request an therefor may result in a totally different output
sent by the server.

If Mozilla doesn't remeber the correct request including the POST parameters, it
should not display any source but a warning indicating, that Mozilla forgot the
request.
Comment 76 Koike Kazuhiko 2001-05-23 20:03:05 PDT
*** Bug 82489 has been marked as a duplicate of this bug. ***
Comment 77 rbs 2001-05-24 21:00:00 PDT
Clearing nsbeta- to trigger re-evaluation. This bug is ugly. It is even more
than dataloss because it can trigger multiple transactions in a db (is there a
keyword for that? 'datagain'? see e.g., the scenario described in bug 81913, and
other duplicates). See also how it has just baffled a number of people in bug 81531.
Comment 78 rbs 2001-05-24 21:10:39 PDT
*** Bug 81531 has been marked as a duplicate of this bug. ***
Comment 79 rbs 2001-05-24 21:56:49 PDT
*** Bug 81531 has been marked as a duplicate of this bug. ***
Comment 80 Aleksey Nogin 2001-05-25 06:36:22 PDT
Copying correctness and highrisk keywords from bug 40867 - they are equally
applicable here.
Comment 81 Chris Hiner 2001-05-29 10:47:26 PDT
*** Bug 83122 has been marked as a duplicate of this bug. ***
Comment 82 doctor__j 2001-05-30 00:42:53 PDT
*** Bug 83221 has been marked as a duplicate of this bug. ***
Comment 83 Viswanath Ramachandran 2001-06-01 16:46:43 PDT
law is not going to be able to look at this for at least 2 milestones, his plate
is full for mozilla0.9.2 and he'll be on vacation after that for a few weeks. if
this is badly wanted, someone is going to have to take it. thanks!
Comment 84 doctor__j 2001-06-08 11:01:49 PDT
*** Bug 84684 has been marked as a duplicate of this bug. ***
Comment 85 Gilles Durys 2001-06-12 04:49:52 PDT
*** Bug 85398 has been marked as a duplicate of this bug. ***
Comment 86 cweiss 2001-06-12 10:53:23 PDT
If anyone would like to see a test case...
Go to http://ntiaotiant2.ntia.doc.gov/test/mozillatest.html
Submit the form then do view source on the results page.
An error message from the server will appear in the source, not the source for
the page you are viewing.
Comment 87 Brian Haskin (Janzert) 2001-06-12 17:22:11 PDT
*** Bug 74834 has been marked as a duplicate of this bug. ***
Comment 88 Aleksey Nogin 2001-06-16 18:35:17 PDT
Test case provided by cweiss@iname.com
Comment 89 rbs 2001-07-07 01:28:17 PDT
There is a patch from vidur on the root bug 40867. Anyone wants to test to see 
if this bug is finally about to be gone?
Comment 90 Boris Zbarsky [:bz] (still a bit busy) 2001-07-07 08:23:35 PDT
rbs:  vidur's patch covers "save as" only.

What needs to happen is that view source needs to use a setup similar to that
one (also passing a cache key and all that).  I'll try to look into that
sometime this weekend...
Comment 91 Chris Abbey 2001-07-07 10:28:22 PDT
While Vidur's patch addresses the simple test case I had posted on that bug it
does not address the one on this bug. Actually it doesn't even try, it's focused
soley on the save as case.

This test case is a much better one than the one I posted.

save as:      re-requests! (number incremented)
view source:  fails completely (server error)
send:         fails completely (server error)
print:        success :)
Comment 92 Boris Zbarsky [:bz] (still a bit busy) 2001-07-09 15:31:38 PDT
I have code in my tree that makes view source pass the test at
http://ntiaotiant2.ntia.doc.gov/test/mozillatest.html just fine (modulo another
cache bug, actually, but that bug causes us to get a too-old version from cache
at times, which is not nearly as bad as what we do now).  The POST data is
remembered and the number of requests is not incremented.

I'm not attaching a patch yet because I'm waiting on feedback regarding some
interface changes I've had to make and because the code has some issues I'd like
to clean up before wasting anyone's time with review...

Comment 93 Jacek Piskozub 2001-07-10 13:42:31 PDT
*** Bug 90203 has been marked as a duplicate of this bug. ***
Comment 94 Boris Zbarsky [:bz] (still a bit busy) 2001-07-17 17:46:25 PDT
*** Bug 80301 has been marked as a duplicate of this bug. ***
Comment 95 Boris Zbarsky [:bz] (still a bit busy) 2001-07-18 15:05:13 PDT
*** Bug 84393 has been marked as a duplicate of this bug. ***
Comment 96 Dwayne 2001-07-19 10:15:23 PDT
*** Bug 91456 has been marked as a duplicate of this bug. ***
Comment 97 Dan Allen 2001-07-22 18:41:25 PDT
I am a web developer and I run into this bug everyday when I am using mozilla 
to test my code.  I can assure you that when view source is choosen, the code 
is reexecuted, and quite frankly it is driving me nuts because I can never 
view the source I am looking for since the page is dynamically generated and 
when the page is reloaded the page is in a different state.
Comment 98 Markus Hübner 2001-07-27 02:18:34 PDT
I just spend several hours till I discovered that mozilla is having major 
troubles with view-source.
Think we should focus on this not to displease the whole web-developer 
community.
Comment 99 Christopher Aillon (sabbatical, not receiving bugmail) 2001-08-13 14:17:07 PDT
*** Bug 95149 has been marked as a duplicate of this bug. ***
Comment 100 bugzilla 2001-08-17 06:45:38 PDT
and even worse, a form will be resubmitted and the data will show up twice in 
email/database/stuff.
that's not really what anyone wants.
the source of the currently loaded page should be in a special variable so that 
it can be easily used for operations such as VIEW SOURCE and SAVE PAGE.
Comment 101 John Keiser (jkeiser) 2001-08-17 11:24:37 PDT
Rather than store source in a variable, storing a hard reference to the entry in
the cache is sufficient.  But that should mainly be for the current page.  Do
normal users really want the source of the 150 pages they've visited today stuck
in memory?

(Though maybe if hard references to the cache allowed the cache to put stuff to
disk and retrieve on use, it would be a different story.)
Comment 102 Darin Fisher 2001-08-17 11:36:35 PDT
there are two ways to solve this problem (both of which are supported by necko)

1) use a hard reference to the cache entry (called a cache token)

2) use a soft reference to the cache entry (called a cache key)

with either of these methods you can identify a cache entry a pull it out of the
cache (disk or mem) without incurring a network hit.  see nsICachingChannel for
details.
Comment 103 R.K.Aa. 2001-09-13 05:06:28 PDT
*** Bug 99449 has been marked as a duplicate of this bug. ***
Comment 104 Boris Zbarsky [:bz] (still a bit busy) 2001-09-16 20:43:19 PDT
*** Bug 99971 has been marked as a duplicate of this bug. ***
Comment 105 Christopher Aillon (sabbatical, not receiving bugmail) 2001-09-19 06:43:38 PDT
*** Bug 100529 has been marked as a duplicate of this bug. ***
Comment 106 Boris Zbarsky [:bz] (still a bit busy) 2001-09-20 07:13:00 PDT
*** Bug 100728 has been marked as a duplicate of this bug. ***
Comment 107 Al Peak 2001-09-20 08:45:35 PDT
I know this has been said before, but:

If developers of dynamic content can't "view source", MOZILLA WILL NOT BE
SUPPORTED BY DEVELOPERS.  It is not acceptable that when I have problem on a
page that I'm developing and go to view source, I CAN"T VIEW IT because VIEW
SOURCE makes ANOTHER request to the server and returns something other than what
I need to see.

How long has this bug been sitting out there?  ALMOST ONE YEAR.  That's one full
year of developers throwing up their hands in frustration, saying, "we can't
support Mozilla or Netscape 6 because we can't debug our pages on it".  You are
slitting your own throats here, and it isn't Microsoft's fault that you are
losing market share (for once).

Fix it.  Fix it now.  I want to support Mozilla.
Comment 108 Chris Campbell 2001-09-20 09:08:08 PDT
Here here!  I can't believe this one has remained a 
problem for so long.  I'm a web developer, and this
is a constant frustration to me and my co-workers.  
Please make it a high priority... I'd hate to see it 
slide any longer.
Comment 109 Sushil Kambampati 2001-09-20 09:15:32 PDT
Well, I don't know what's got everyone all twitchy about this, but I agree with
the last two commenters.  I started and stopped using Mozilla for debugging and
browsing in general back in May.  Even Netscape 4.78 is no good, it seems to
hide my html comments.  I went back and am sticking to 4.77.  If I weren't a
Linux developer, I'd switch to IE now.
Comment 110 vivek 2001-09-20 09:40:53 PDT
Actually, if you follow the trail back, I think it's been 
hanging around for significantly longer than a year - it's just
that every time it looks like it's going to be fixed, it gets 
bumped back. I've resorted to using emacs, w3m, lynx or wget to
debug pages, and I think I'll look at Opera and/or Galeon too: 
It took far too long for this to even be acknowledged as something 
that needed fixing. And since people seem to be talking about using 
the cache [unless I've misinterpreted] I'd just like to repeat 
something that seems to have been overlooked (again):
  
  What about pages that are displayed, but not in the cache?

Comment 111 Nathan Bidwell 2001-09-20 09:49:53 PDT
<QA_Ignore Rant=on>
I'm sorry that this bug makes it impossible for you to develop with mozilla. 
Anyone who is reading this HATES this bug.  Bitching about it will only make
people resent you.  You want it fixed NOW?  There are a couple of things you can
do to help.
1. If you're a developer yourself, look into the problem and *try* to fix it. 
(I know it's a hard problem.  If it were easy, something as high profile as this
wouldn't be a problem anymore, would it?)
2. Add your vote to the 67 already here.  (Not to mention the 68 CC's if I can
count correctly.)
3. Advocate fixing this bug somewhere more effective, like to any developers you
know personally, or on the newsgroups.
4. Really put your money where your mouth is.  Find someone who can code and pay
them to fix this bug for you.

What does another message of 'This is a really bad bug that I can't use Mozilla
with, fix it NOW!!!!' really do?  Well, it adds another comment to bugzilla that
anyone interested in actually helping fix the bug needs to wade through first. 
Thus they have /less/ time to do what you really wanted them to do.  Remember,
there are a number of bugs where such comments have gotten so bad that they were
closed and re-reported just so that no-one had to wade through the muck anymore.

To reiterate: if you want to support having a bug fixed, but don't have the
time/skills to work on it yourself, and don't have any information that would
directly help someone working on the bug, vote for it or put your name on the CC
list.  There is little else you can directly do to help.  Don't waste the time
of those actually trying to get work done.

135 people don't need to get email just because you think this is a bad bug.  If
they didn't already think that, they wouldn't be following this bug.  You're
preaching to the quire.

</QA_Ignore>
Comment 112 Boris Zbarsky [:bz] (still a bit busy) 2001-09-20 10:05:45 PDT
> What about pages that are displayed, but not in the cache?

Handle them just like a reload.  Re-request if there was no post data, prompt
before re-requesting if there was post data.
Comment 113 Steve Grecni 2001-09-20 10:08:13 PDT
As this bug does have 67 votes for it, I'm sure the mozilla developers are well
aware of it.  I'm a linux web developer and I for one, use mozilla as my primary
browser.  Every once in awhile I bust out netscape 4.77 to see if I have any
broken tables or what not.   While it's annoying that I cannot use view source
on form posts but I'm just smart about programming and I've been able to make do
without view source.   I'm confident that this bug will get fixed in due time,
it is targeted for moz 1.0.

I've just tested it out and here are some tests I did:  (0.9.4)

1) normal get, no post data, seems to show the correct page, no addition GET is
issued

2) form submit via post to itself, the first page is shown, not the most recent,
no addional GET is issued

3) form submit via post to another page, the correct view source is shown, no
addional GET is issued

So from my 10 minutes of testing here, it looks like mozilla can pull the page
from the cache, but it can get confused about which copy of the page to pull
from the cache, so a page that you hit twice, but returns different results may
show incorrect view source.  In none of my test cases did mozilla make another
fetch from the server as all the page were in the cache.

Someone please correct me if I tested wrong.

Give the mozilla developers a break a lot of them work hard with little to no
pay.  And they have a LOT bugs to deal with.  This one's *almost* there.
Comment 114 Wilfried Goesgens 2001-09-20 10:15:12 PDT
Hearing of opera in this 'Thread': 
Opera has the nice feature to provide the choice of which program to use for
viewing. 
Sorry, no Fix, no patch, just another feature-request...
Comment 115 Wilfried Goesgens 2001-09-20 10:25:26 PDT
> > What about pages that are displayed, but not in the cache?

> Handle them just like a reload.  Re-request if there was no post data, prompt
> before re-requesting if there was post data.

AIIK bad idea. if you have a Serverside Application proccessing the post data
in dependence of the last request (and its not stateless) you might only
get an 'well, my database doesn't love you **** off' error.

What about a 'Memory waste' mode for developers copying the data to another 
buffer vor the view-source? Or even store it to the Disk?
this would allso ease the use of an external viewer/editor.
Comment 116 Adam Hauner 2001-09-20 10:27:09 PDT
> What about pages that are displayed, but not in the cache?

Developers _NEED_ to see source of actually viewed page. So source code must be
stored in memory without using cache system. Maybe this could be feature for
developers and they have to enable it in preferences. But developers really NEED
this.

You CANNOT use for this type of pages any cache system because some
cache-directives in HTTP1.1 restrict caching (RFC2068, 14.9.1).

> Handle them just like a reload.  Re-request if there was no post data, prompt
> before re-requesting if there was post data.

This is right reverse, what developers need. It's correct for programmer's eye
and it is correct according to HTTP standard, but developers need something else.

Comment 117 Wiggins 2001-09-20 10:37:26 PDT
Not to mention...as I stated way way back when. The generated page depends on
much more than GET or even POST information.  The state of Cookies, or even
something such as time which mozilla shouldn't track can effect the output of a
page. A page that is "POSTED" to could change depending on whether it was after
work hours for instance.  There are to many examples of this to list, which is
why it is so crucial that the original source is displayed, to name a few, time,
screen resolution in a user's display (could change while viewing a page which
would change (or would it?) the javascript object storing this information),
IP/Domain Name (in the case of a renewed DHCP lease), etc.  Or something could
change on the server side (although in most cases these would be poor designs on
the server side).

Bottom line, the original source must be used, this is not just a matter of
GET/POST/re-POST......

I have been watching this bug for a while as well as one of the dependents,
there was a lot of effort put forth on it, and then we lost someone, etc. Has
the bug been "re-assigned" to someone that can actually work on it, or is it
still waiting in the wings for someone familar enough with the source?
Comment 118 Aleksey Nogin 2001-09-20 10:47:57 PDT
> Opera has the nice feature to provide the choice of which program to use for
> viewing. 
> Sorry, no Fix, no patch, just another feature-request...
This is known as bug 8589

> What about pages that are displayed, but not in the cache?
As far as I understand the discussion in bug 40867, the idea is to make sure
that this never happens - while you have a page opened is a window, the window
would hold a cache reference that would prevent the page from being removed from
the cache.

> You CANNOT use for this type of pages any cache system because some
> cache-directives in HTTP1.1 restrict caching (RFC2068, 14.9.1).
I believe this is not true. You can cache whatever you want, as long as you do
not try to serve the cached page again. Another way to lok at it is to say that
the cache is simultaneously a "view source" cache and a "web cache". If you have
a document, that is not supposed to be "web-cached", you still put it into the
cache for the "view source" purposes and than, but do not use it for serving
future web requests...







Comment 119 Stephen Anderson 2001-09-20 10:58:50 PDT
Question.  Is it necessary to have the View Source capability for any other page
but the one currently being viewed?  I don't think it is.  So can't we just have
a memory buffer attached to each browser window which stores the RAW html for
the currently displayed webpage (or webpages in the case of frames)?  This would
be COMPLETELY independant of the cache system.  Sure it would duplicate a little
data, but who cares.  It would never store this data (like the cache) because it
would only ever have the currently displayed page in it.  This data could then
be used for view-source and printing purposes.
Comment 120 Boris Zbarsky [:bz] (still a bit busy) 2001-09-20 11:03:14 PDT
> Is it necessary to have the View Source capability for any other page
> but the one currently being viewed?

Hitting back and then viewing source is not uncommon....

Comment 121 Chris Campbell 2001-09-20 11:26:37 PDT
The more robust solution that would allow hitting
the back button and then viewing source would be
nice BUT I don't think it's absolutely necessary.

stephena@hiwaay.net's proposition sounds simple
and could probably be implemented much more
easily, no?  And this would go 90% of the way
towards satisfying web developers' gripes.
Comment 122 Adam Hauner 2001-09-20 11:32:55 PDT
> I believe this is not true. You can cache whatever you want, as long as you do
> not try to serve the cached page again. Another way to lok at it is to say that
> the cache is simultaneously a "view source" cache and a "web cache". If you have
> a document, that is not supposed to be "web-cached", you still put it into the
> cache for the "view source" purposes and than, but do not use it for serving
> future web requests...

Yes, I could fully agree if we divide problem for 'web cache' and 'view-source
cache'. 'Web cache' is defined by HTTP 1.1 and Mozilla HAVE TO RESPECT this RFC.
So, 'view-source cache' is IMHO only one solution of our problem. If you agree,
is there question, that 'view-source cache' will be enabled for all users or
will be enabled only on user wish. I think, that second case is correct.

Comment 123 Darin Fisher 2001-09-20 11:41:23 PDT
vivek: all content (except that marked with a 'Cache-control: no-store' header)
is stored in the cache.

IE seems to generate HTML for you when the requested page doesn't live in its
cache, and IMO so should we.  this is necessary to support File->SaveAs as well.
Comment 124 vivek 2001-09-20 11:56:04 PDT
Darin: Ok, but if we are generating or refetching in any way, then we 
are not doing a genuine 'view-source', and the user should be warned 
and given the option to abort. [As with re-posts on back/forward]. 
'view-source' has to mean 'Show me the _exact_ thing you rendered into
this page, without triggering any side effects' or it hurts more than
it helps.
Comment 125 Aleksey Nogin 2001-09-20 12:15:47 PDT
Answering Stephen Anderson 2001-09-20 10:58:
> So can't we just have
> a memory buffer attached to each browser window which stores the RAW html for
> the currently displayed webpage (or webpages in the case of frames)?
See the complete list of bugs that are dependent on bug 40867 - we want not only
to be able to do "view source", but also "save as" and "send page". The "send
page" requires us to keep not only HTML, but also images and other data. Also,
if you are viewing a page with frames, then you have to keep lots of HTML pages...

> This data could then
> be used for view-source and printing purposes.
As I understand, the printing problem is easier and is separate - we do not need
the original source for printing, and the data that is kept around for
displaying  the page is sufficient to also print it.

Answering: Adam Hauner 2001-09-20 11:32
> Yes, I could fully agree if we divide problem for 'web cache' and 'view-source
> cache'.
Note that this division only has to be "logical", not "physical". In fact, there
is nothing wrong if both share the same code, the same mechanisms and the same
storage area, all called "Mozilla cache" - as long as entries in that cache are
only used for appropriate purposes. As far as I understand, the current
proposition is exacly that - to extrend Mozilla caching mechanism so that it can
be used for both "web caching" and "source caching" purposes.

Answering Darin Fisher 2001-09-20 11:41:
> all content (except that marked with a 'Cache-control: no-store' header)
> is stored in the cache.
IMHO, it's reasonable to have an implementation that would have problems showing
the source "Cache-control: no-store" documents. After all, if you are a web
developer, you can just avoid using that header while the page is being developed...
Comment 126 Al Peak 2001-09-20 12:28:29 PDT
> Yes, I could fully agree if we divide problem for
> 'web cache' and 'view-source
> cache'. 'Web cache' is defined by HTTP 1.1 and
> Mozilla HAVE TO RESPECT this RFC.
> So, 'view-source cache' is IMHO only one solution of
> our problem. If you agree,
> is there question, that 'view-source cache' will be
> enabled for all users or
> will be enabled only on user wish. I think, that
> second case is correct.

  I would vote for the former, "enabled for all users" since this is the
behavior that most users coming from Netscape 3/4.x and IE would expect, AFAIK.
 Is there any instance that "view page source" should, reasonably, not view the
current page but rather fetch a new page from the server and show its source?

  Of course, I'd still cheer for "enabled by choice" if that's the only way this
will get in.


  BTW, my apologies for my previous "Fix it. Fix it now" rant.  I was out of
line.  I can see that there are several people working diligently on this, and
that they've been plugging for some time.  Keep it up.
Comment 127 John Keiser (jkeiser) 2001-09-20 13:23:01 PDT
The currently viewed page can have a hard reference to it.  That way, any page
that is viewed *will* be in the cache.  This solves the "viewed page" problem.

The bigger problem is when the page has been changed by JavaScript--how do you
show that source, and which one do you show--but I think the original source is
good enough for now.
Comment 128 cweiss 2001-09-20 15:53:04 PDT
How does Netscape 4.7 handle view source?
Could the same be done here?
Comment 129 Adam Hauner 2001-09-21 00:04:13 PDT
ayn2@cornell.edu:
> After all, if you are a web developer, you can just avoid using
> that header while the page is being developed...

It's not true and not relevant. Developers need view source everytime, not
depending on headers served by web-server (very often servers are configured by
other person).
---
So, Bill Law, what you think about discussion on this topic? 
(BTW this bug is 7th the most wanted bug in Bugzilla).
Comment 130 John Keiser (jkeiser) 2001-09-21 00:35:40 PDT
To solve the problem completely and fully:

Just make hard references allow the data to go off into the disk--just not to be
deleted.  This would allow us to save memory but still keep every single bit of
session history around in case we need it.  Just have every single history item
keep its very own hard reference.  You could have a pref that says whether or
not to do this for non-currently-viewed pages (for people with the pref off, it
would simply use the weak ref, meaning the page could be deleted).

But I don't expect this as a first-pass solution.  Just being *able* to use the
cache keys seems to be a big enough problem.
Comment 131 Robert Kaiser 2001-09-21 08:00:14 PDT
IMHO, we only need a mechanism for the currently viewed content. If someone does
back + view source, that's no problem, we already have mechanisms for
back/forward, they will apply, and then we again have viewed content we can
show, right?

just my 2c
Comment 132 Boris Zbarsky [:bz] (still a bit busy) 2001-09-21 10:02:39 PDT
*** Bug 100939 has been marked as a duplicate of this bug. ***
Comment 133 Boris Zbarsky [:bz] (still a bit busy) 2001-10-12 06:50:49 PDT
*** Bug 102499 has been marked as a duplicate of this bug. ***
Comment 134 Matthias Versen [:Matti] 2001-10-13 11:59:24 PDT
*** Bug 104607 has been marked as a duplicate of this bug. ***
Comment 135 Boris Zbarsky [:bz] (still a bit busy) 2001-10-18 16:17:13 PDT
*** Bug 105554 has been marked as a duplicate of this bug. ***
Comment 136 Lars Linek 2001-10-19 11:46:54 PDT
*** Bug 105683 has been marked as a duplicate of this bug. ***
Comment 137 doctor__j 2001-10-23 06:02:22 PDT
*** Bug 106230 has been marked as a duplicate of this bug. ***
Comment 138 Gilles Durys 2001-11-01 03:58:45 PST
*** Bug 107948 has been marked as a duplicate of this bug. ***
Comment 139 Darin Fisher 2001-11-08 14:46:01 PST
*** Bug 64100 has been marked as a duplicate of this bug. ***
Comment 140 castageg 2001-11-09 06:32:20 PST
Edward Castagna wrote:

After I mentioned on the  bug 64100 stream that the save as behaves
on Netscape Browser 6.1, I got a response back...
Response: ====

I'm using the latest builds from Mozilla for a while now, and the 
earliest build I have on my system here is one from October 10, and with 
that version I still get the prompt.

The Netscape 6.1 build is based on the Mozilla 0.9.2.1 milestone source 
code. I don't know if Netscape modifies the code a lot (don't think so), 
but it is very well possible that some bugfixes has changed the 
behavioru of the prompt box.

I'd recommend you add your findings to the Bugzilla system, so 
programmers working on the source code might track where the change 
occured...

Kind regards,

Kris Ven
Comment 141 Chase Tingley 2001-11-16 10:47:44 PST
*** Bug 110489 has been marked as a duplicate of this bug. ***
Comment 142 R.K.Aa. 2001-11-18 22:48:00 PST
*** Bug 110717 has been marked as a duplicate of this bug. ***
Comment 143 Gilles Durys 2001-11-19 12:53:13 PST
*** Bug 110827 has been marked as a duplicate of this bug. ***
Comment 144 Bill Law 2001-11-19 17:20:27 PST
->mozilla0.9.9
Comment 145 R.K.Aa. 2001-11-20 04:00:25 PST
*** Bug 110959 has been marked as a duplicate of this bug. ***
Comment 146 Doron Rosenberg (IBM) 2001-11-21 02:23:23 PST
*** Bug 110864 has been marked as a duplicate of this bug. ***
Comment 147 Adam Hauner 2001-11-22 07:09:10 PST
*** Bug 111466 has been marked as a duplicate of this bug. ***
Comment 148 Boris Zbarsky [:bz] (still a bit busy) 2001-12-03 12:19:01 PST
*** Bug 113304 has been marked as a duplicate of this bug. ***
Comment 149 r.navalinskas 2001-12-07 00:24:46 PST
Is there a big problem to keep source of the page in memory ? Memory is cheap
these days, and it's user's problem if he/she opens 100 windows or more...

Comment 150 Matthias Versen [:Matti] 2001-12-13 06:33:29 PST
*** Bug 115059 has been marked as a duplicate of this bug. ***
Comment 151 Boris Zbarsky [:bz] (still a bit busy) 2001-12-19 13:14:50 PST
*** Bug 116070 has been marked as a duplicate of this bug. ***
Comment 152 Philip Tellis 2001-12-28 01:56:24 PST
Ok, the problem is worse than just the source code being cached.
Even the contents of textareas do not change.

for a simple example, make a form with a textarea, submitted through post.  let
your cgi program change the text in the textarea.  The resultant page will still
have the old text.

If instead, you use Content-type: text/plain instead of text/html, you find that
the CGI has provided the correct output.
Comment 153 r.navalinskas 2001-12-28 02:19:28 PST
Source should be attached to the window, not to the specific URL(that URL could
produce different contents on each request). If window contents are reloaded,
only then source changes. Is it a problem to have in-memory copy of window
contents (as it was sent from the server) ?
Comment 154 a_geek 2001-12-28 03:28:37 PST
In comment #152, Philip Tellis suggest that there is also incorrect handling
of form data. I'd like to know if the problem he reports is related to the
interaction of the show-source part of the browser and the form manager which
sometimes remembers more values than is good (imho).
Comment 155 Philip Tellis 2001-12-28 04:20:50 PST
more use tells me that it is not just textareas, but any form element.  Shows
the cached values, or what was entered by the user, rather than what the cgi
returns.
Comment 156 Boris Zbarsky [:bz] (still a bit busy) 2001-12-28 08:11:57 PST
*** Bug 117197 has been marked as a duplicate of this bug. ***
Comment 157 Jon Hall 2001-12-28 10:16:15 PST
The form caching bug you are refering to is probably this one 
http://bugzilla.mozilla.org/show_bug.cgi?id=46845

Unfortunately Mozilla feels the current behavior is correct, please vote for 
it...it's been ignored for such a huge bug imo. At least this bug has a target 
milestone.
Comment 158 Taral 2001-12-28 11:13:04 PST
About view-source on history pages:

Although it's useful to have history pages render quickly, I don't think it's
reasonable to keep the original source around for them too. As a developer, if
I'm going to want to see the source, I only expect the browser to be able to
pull it without a server fetch if I'm doing it on a current page, not a history
page. So per-window "latest-page-source" might be the answer here.

Anyone else think this way?
Comment 159 vivek 2001-12-28 11:34:23 PST
Taral: No, absolutely not. If we can view a page w/o refetching it, then view
source _must_ be able to display the source w/o refetching/triggering side effects.
Comment 160 Taral 2001-12-28 11:41:17 PST
I disagree. If necessary, a warning can be displayed that the original source is
no longer available, with options of "reconstructed source" and "fetch from server".

I don't think it's unreasonable to tell developers that if they want the source,
it's "now or never".
Comment 161 Ross Golder 2001-12-28 12:30:35 PST
Taral: No, absolutely not. If we can view a page w/o refetching it, then view
source _must_ be able to display the source w/o refetching/triggering side effects.

In other words, I second vivek's point - we can't rely on reconstructed or
refetched source to highlight a server-side problem.

--
Ross
Comment 162 Nathan Bidwell 2001-12-28 12:36:09 PST
<QA ignore>

We've been here before, see the discussion of cache tokens.  (Starting around
comment 102 I think...)

Also remember that every time you make a comment here, 200+ people get email.
</ignore>
Comment 163 Christopher Aillon (sabbatical, not receiving bugmail) 2001-12-29 18:04:38 PST
*** Bug 117391 has been marked as a duplicate of this bug. ***
Comment 164 Chris Lyon 2002-01-01 12:55:52 PST
*** Bug 117634 has been marked as a duplicate of this bug. ***
Comment 165 Bill Law 2002-01-02 12:03:15 PST
Modifying summary to include the phrase "page source," per request.
Comment 166 Jonas Jørgensen 2002-01-07 03:22:48 PST
*** Bug 118536 has been marked as a duplicate of this bug. ***
Comment 167 Christopher Aillon (sabbatical, not receiving bugmail) 2002-01-07 06:49:22 PST
*** Bug 118562 has been marked as a duplicate of this bug. ***
Comment 168 Olav Vitters 2002-01-09 10:32:52 PST
*** Bug 119008 has been marked as a duplicate of this bug. ***
Comment 169 R.K.Aa. 2002-01-13 13:00:52 PST
*** Bug 119802 has been marked as a duplicate of this bug. ***
Comment 170 Matthias Versen [:Matti] 2002-01-18 10:22:19 PST
*** Bug 120804 has been marked as a duplicate of this bug. ***
Comment 171 Bill Law 2002-01-18 17:03:19 PST

*** This bug has been marked as a duplicate of 40867 ***
Comment 172 Ben Bucksch (:BenB) 2002-01-18 17:33:18 PST
vrfy
Comment 173 Dan Tobias 2002-01-18 17:49:00 PST
Why is this suddenly a dupe of bug 40867 now, when way back in comment 1 and
comment 2, over a year ago, it was remarked that we shouldn't be so optimistic
as to close this one as a dupe?  What has changed recently?

At any rate, I don't really care which bug is considered a dupe of which, but I
would like to see it fixed... the lack of a reliable and consistent "View
Source" is one of the biggest flaws in the current Mozilla.
Comment 174 Leston Buell 2002-01-18 18:39:54 PST
Why has it taken so long to identify this as a dupe? Marking this bug as a
duplicate messes up two things:

1. Votes, of which this bug has 162.
2. Most frequently reported bugs. This bug was at the top of the list 
   just yesterday, with about 76 dupes, as i remember. Now that this 
   bug has been duped, the bug does not appear in the list at all:
   <http://bugzilla.mozilla.org/duplicates.cgi>

These two things aren't important if things actually get moving on bug 40867,
but that doesn't appear to be really happening. The last patch submitted for
40867 was back in July.
Comment 175 Jeremy M. Dolan 2002-01-18 20:52:36 PST
Can someone please explain why this should be a dupe and not a dependency of
40867? If a fix should knock them both out together, great, but the case of view
source will still require seperate verification after 40867 is fixed.

Closing out a bug with *the* most votes with absolutely no comment, and
verifying it minutes later with absolutely no comment, isn't the best PR move
I've seen.

This has screwed up dupes, votes, and the dependency tree quite badly.
Comment 176 Ben Bucksch (:BenB) 2002-01-18 22:15:00 PST
> Closing out a bug with *the* most votes with absolutely no comment, and
> verifying it minutes later with absolutely no comment

I verified because:
- I always thought that they are both the same bug (see my initial comments),
but the developer wanted separated bugs, because the issues *might* be
different, so he got his own bug. (His priviledge as developer.)
- The bug filer, assignee and dupper are identical. Again, he knows best what
the facts are. If he found out that the bugs are in fact identical, dupping them
is the logical step
- I wasn't aware how *many* votes, ccs and dups this bug really has, until I saw
the "email sent to" confirmation. (I counted roughly 300 emails sent.)

Now being aware of it, I think, it might make sense to keep this bug open, just
so we have correct vote/dup statistics. law, OK? If so, please reopen.
Off to spamming 300 people again... :-(
Comment 177 Leston Buell 2002-01-18 22:29:12 PST
Reopening as per comments by Ben Bucksch in comment 176, to avoid problems with
lost votes, dupe count, and dependency tree.
Comment 178 Joosep-Georg Järvemaa 2002-01-20 23:41:49 PST
Re: comment 176

> Off to spamming 300 people again... :-(

http://www.dictionary.com/cgi-bin/dict.pl?term=spamming says:

> spam
> 
> Unsolicited e-mail, often of a commercial nature, 
> sent indiscriminately to multiple mailing lists, 
> individuals, or newsgroups; junk e-mail.

So, sending those notifications isn't spamming, i think.
Comment 179 Bill Law 2002-01-22 11:18:45 PST
I closed this bug because I'm sick and tired of it, mostly.  It was written 
when the problem and its solution was much simpler.  viewsource.js took a URL 
as argument and did some docshell webnavigation magic to load that URL in "view 
source mode."  I envisioned passing an additional post-data argument that would 
be used in conjunction with the URL to fetch the appropriate source from the 
cache.

But then, interfaces were enhanced/changed and we didn't put in place a 
mechanism for handling post-data.  Later, "view source" was fundamentally 
changed so that it was handled via a separate protocol handler rather than via 
docshell attributes.

That made it very difficult to fix this problem.  The only solution at this 
point involves work beyond the scope of the original purpose of this bug.  The 
only ongoing effort, I believe, to solve the problem is taking place under the 
auspices of bug 40867.  If you read http://bugzilla.mozilla.org/show_bug.cgi?
id=40867#c186 it is obvious that this aspect of the problem is sufficiently 
addressed by that bug.

Myself, I don't want to keep around bugs that I am not going to work on and are 
outside of my control.  I can understand why other people might prefer to keep 
a separate bug open, though.

I have to get this bug off my list.  I'm going to re-assign it to match bug 
40867.  If it is going to get fixed, then it will be by the same people who fix 
that one.
Comment 180 Adam Lock 2002-01-23 07:49:08 PST
Bug 115328 deals with a similar issue for persistence.

I'm futuring until someone comes up with an idea how this can be done. My
feeling is this is an issue for the cache/DOM folks.
Comment 181 Oliver Klee 2002-01-23 08:31:36 PST
*** Bug 121436 has been marked as a duplicate of this bug. ***
Comment 182 vivek 2002-01-23 08:46:17 PST
Peachy. Nearly 3 years of discussion (bug 6119) and yet again, this bug 
gets bumped back. You could have just marked it as WONTFIX to start with.
Comment 183 Michael Lefevre 2002-01-23 08:52:47 PST
i'm only an outsider, but futuring this bug seems a little crazy to me.

this bug is both _the_ most voted for (164 votes), and most duplicated (75 
dups) and it's mentioned in the release notes. it's pretty clear that it's one 
of the biggest outstanding issues for many users, and you're futuring it?

maybe it's not your responsibility and maybe it wasn't the responsibility of 
the person who just dumped this bug on you either, but surely someone should 
take responsibility for it?  please?
Comment 184 Brian S. Craigie 2002-01-23 09:14:26 PST
Referring to comment #183, suggest you see bug 40867
http://bugzilla.mozilla.org/show_bug.cgi?id=40867

It seems to be the same bug, and something's happening on that.

Brian
[just another outsider, upset at the apathy about this bug too]
Comment 185 Andrew Hagen 2002-01-23 11:28:15 PST
There are currently six bugs that are blocked by bug 40867, the reuse/reload
without refetch bug. They range in Target Milestone from 0.9.9 to 1.2 to Future.
As one of the dependents of bug 40867, this bug is, of course, currently set to
future.

The following two bugs are dependent on bug 40867 and set to 0.9.9: bug 17889,
Changing character set reloads the page from web; and, bug 84106, Not correctly
retrieving post data when saving a page or frame generated from a form POST.

This bug is as important as those two. This bug affects view source. It only
affects a subset of users, since most don't know or care about view source. That
subset, however, includes HTML developers. I'm not an HTML developer myself, but
it's important to keep the HTML development community happy.

I support setting the target milestone to 0.9.9 or 1.0. 

As for a practical solution, bug 56346 has been fixed, so all pages should be
cached, either in memory or on disc. The current HTML document should be cached
either in memory or on disc. Can't we query the cache to learn where the
document is cached? Then, open that file from cache and display in the view
source window?

Comment 186 Boris Zbarsky [:bz] (still a bit busy) 2002-01-23 12:05:12 PST
> Can't we query the cache to learn where the document is cached?  Then, open
> that file from cache and display in the view source window?

This is what bug 40867 is all about.  We _can_ do it.  Just not from javascript
(yes, we can read data from the cache from javascript, but then we can't do
anything with that data.  No we can't tell the docshell, which _can_ do
something with the data, to read it from cache unless we do it from C++).  And
the people in charge of the API have some reasons not the expose the low-level
APIs that can do this to javascript.

Possible fixes to this bug:

1)  Wait for something cool to happen in bug 40867
2)  Create a C++ service which will be scriptable, take data from view source
    ("data" means post data, url, cache key, charset, docshell) and load that
    data in the view source docshell by calling nsIDocShell::loadURI (not
    scriptable), instead of nsIWebNavigation::loadURI (scriptable)
3)  Add a cache key (or history entry) parameter to nsIWebNavigation::loadURI.
    Then use that directly from viewsource.js

#1 is not likely to happen anytime soon because it's being overengineered.
#2 is something I could maybe do if I had lots of time, which I don't (I'd need
   to figure out how to get some C++ thing scriptable and instantiated in JS).
   This method is also a gross hack.  May be worthwhile if we need this bad
   right now and
#3 would need approval from rpotts@netscape.com , who owns that interface.  I've
   mailed him with the suggestion....  He vetoed it once, a few months back but
   maybe the lack of progress on bug 40867 will help....
   someone has the time to do it.
Comment 187 Wilfried Goesgens 2002-01-23 12:19:16 PST
>2)  Create a C++ service which will be scriptable, take data from view source
>    ("data" means post data, url, cache key, charset, docshell) and load that
>    data in the view source docshell by calling nsIDocShell::loadURI (not
>    scriptable), instead of nsIWebNavigation::loadURI (scriptable)

Why not do this via the 'file save as' mecanism which allows me to 
give an executable to view the unknown-mime-type or to save it to
disk? 
You could modify the mime-type to something like html-view-source
or that...
So one could set his desired editor and even more people would
be happy... 
Comment 188 Andrew Hagen 2002-01-23 12:50:20 PST
Thanks to Boris Bzarsky for the explanation.

Like the last comment said, instead of an extra layer/service or a potential
security hole, we could just call a text editor. In Windows, IE 6 still calls
notepad.exe for view source. It's ugly, but it gets the job done. HTML
developers don't want a pretty interface as much as they want the original
source file.

Comment 189 Bishop Clark (LC957) 2002-01-23 13:03:38 PST
How's that work for ^R re-using the same window to show the same source again? 
I don't want it shelling out ; I think that's nearly the lamest idea, and half
of my mind suggests it's a troll.  Toss up a kiosk window, enable the hotkeys
(ctrl-[xcrwqnsepia]) and show the data sucked from the URL instead of rendering.
 When did it become complicated with MIME-types again?  Why do I need to run
about closing a million new editor windows?

Comment 190 Thomas Swan 2002-01-23 13:35:01 PST
Why can't your throw the cached item into a temp file and open it up in the
viewer window?
Comment 191 Boris Zbarsky [:bz] (still a bit busy) 2002-01-23 14:22:45 PST
> Why can't your throw the cached item into a temp file

The hard part would be telling the docshell that the file should be shown as
source, not just as HTML, but that could be done.....  Count this as way #4.

This has approximately the ugly hack coefficient of way #2, especially since I
think it would require adding knowledge of view source to things like the
uriloader which should have no such knowledge.
Comment 192 Ben Bucksch (:BenB) 2002-01-23 18:22:30 PST
> yes, we can read data from the cache from javascript, but then we can't do
> anything with that data.

Why can't you do anything with the data in JavaScript? *If* you have the right
HTML source as string, just push it into a window (as text/plain, or do a simple
TXT->HTML conversion and something like document.write()). You'd have no
pretty-printing, but better correct than pretty.
Comment 193 Thomas Swan 2002-01-23 19:41:38 PST
I think the problem is that it's not stored in raw form, but in a digested format.

I agree the "throw to a temp file" is an ugly hack, but it was only an idea,
albeit not a very good one.   The URI loader should have no knowlege of source
file.   Unless you did something like raw:// or source:// in which case you
_might_ be able to do something...  I think it would be way too much work to go
that route, and I'm not sure if it would be appropriate.
Comment 194 Boris Zbarsky [:bz] (still a bit busy) 2002-01-23 22:39:23 PST
> You'd have no pretty-printing, but better correct than pretty.

If we believed that we wouldn't have syntax highlighting either....

Oh, and doing postData correctly via the scriptable cache interfaces would be a
gross hack... we would need to duplicate nsHttpChannel::GenerateCacheKey in JS
and then hope that the algorithm never changes.  A bad idea, in general....

This is why ideally we want the HTTP channel to do all the cache access for us.
Comment 195 Adam Lock 2002-01-24 09:48:18 PST
CC'ing Gordon & Radha for ideas how to pull this data out of cache
Comment 196 Andrew Hagen 2002-01-26 07:22:56 PST
It's a shame we can't just use the same functionality as <context menu> | Edit
Page In Composer | HTML source tab.  I bet the embedded products, like Galeon,
don't include Composer.
Comment 197 a_geek 2002-01-26 08:13:58 PST
Hello,

(as could be deemed obvious) this bug is a big obstacle when you develop
with Zope because it makes debugging hard or impossible.
Example: I just got an error message that read:

"...

Troubleshooting Suggestions

    * The URL may be incorrect.
    * The parameters passed to this resource may be incorrect.
    * A resource that this resource relies on may be encountering an error.

For more detailed information about the error, please refer to the HTML source
for this page.

If the error persists please contact the site maintainer. Thank you for your
patience.

[Powered by Zope]
"

But when I tried to "view source" of that page, all I (naturally) got was a
page containing the frameset statement and a <noframes> section saying
"This requires a frame-capable browser".

Major bummer :(

Best,
--Toni++
Comment 198 Doron Rosenberg (IBM) 2002-01-26 08:39:02 PST
People, this bug is not for bitching/complaining, we've got newsgroups for that.
Comment 199 Dan Tobias 2002-01-26 08:51:51 PST
Re comment 197: If you get a frameset when viewing source, you should try "View
Frame Source" (a right-click option when you have the mouse pointer somewhere in
the framed content).

You might still not find what you're looking for, in the case of dynamically
generated frame content, due to this bug, but at least that gives you a chance
of finding it, while viewing the frameset source will still just give you the
frameset code even after this bug is fixed.
Comment 200 Dan Allen 2002-01-26 21:29:38 PST
Responding to comment #188:

In the essence of time, it would be nice if there were two options to view
source, one to view source as it works now (and you can fix this whenever you
feel like it) and one to view the source in an external editor.  If the second
option is choosen, then it would take the cached source and spawns an external
editor, but this source would be the source already retrieved and would not have
to repost the form data or retrieve the page again (sort of what Konqueror
does).  Then you wouldn't have to worry about syntax since the editor can do the
syntax highlighting.  If you could understand why we are all voting for this
bug, it is because we need the actual source now, and then you can take as long
as you would like to do it correctly with the javascript mozilla interface. 
Just a thought. 
Comment 201 Boris Zbarsky [:bz] (still a bit busy) 2002-02-02 17:29:15 PST
*** Bug 123166 has been marked as a duplicate of this bug. ***
Comment 202 Matthias Versen [:Matti] 2002-02-08 17:07:11 PST
*** Bug 124509 has been marked as a duplicate of this bug. ***
Comment 203 Neil Marshall 2002-02-12 15:52:44 PST
*** Bug 125095 has been marked as a duplicate of this bug. ***
Comment 204 CoL 2002-02-14 08:01:11 PST
Re comment <a
href='http://bugzilla.mozilla.org/show_bug.cgi?id=55583#c200'>#200</a> and to all.
This is a great idea, and with this the problem could be solved in (before?)
mozilla 1.0, and not in future. As we can see, this is a very important bug,
problem for many people.
Comment 205 André Schild 2002-02-14 08:12:13 PST
If comment 200 is feasible, then go for it.
I realy don't matter in what format/application the original received source is
shown.

The internet explorer 5.x too uses the notepad to display the source.
Comment 206 Boris Zbarsky [:bz] (still a bit busy) 2002-02-14 08:14:20 PST
Actually, I think implementing comment #200 decently in an XP way would take
longer than fixing bug 40867 (which Rick is actually working on right now).
Comment 207 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-16 06:34:21 PST
*** Bug 125866 has been marked as a duplicate of this bug. ***
Comment 208 Christopher Curzio 2002-02-19 07:37:02 PST
Yes, this issue is extremely painful with regards to attempting to view the
source AFTER a form submission, when the URL is the same. 

I'm working on a system that deals with lots of PHP files, and many of these
files use forms. After submitting a form through the PHP file, the URL will be
the same, but the content will be different - the actual result of the form
submission.

Unfortunately, "View -> Source" on the result only brings up the original form
source. Not terribly helpful when debugging.
Comment 209 Chris Campbell 2002-02-19 09:30:22 PST
A friend sent me a work-around to this bug which I have as yet not seen
mentioned in the comments here.

If you create a bookmark with the following bit of javascript, it will use the
DOM's innerHTML attribute to open a new window containing the currently viewed
page's HTML source.  This one works even after form submissions, so it's just
what's needed by web application developers.

Here's the javascript.  I'll break it up here so it's easier to read, but of
course it should all go on one line.

javascript:function htmlEscape(s){s=s.replace(/&/g,'&amp;');
s=s.replace(/>/g,'&gt;');s=s.replace(/</g,'&lt;');return s;}
x=window.open(); x.document.write('<pre>' + htmlEscape('<html>\n' + 
document.documentElement.innerHTML + '\n</html>')); x.document.close();
Comment 210 Boris Zbarsky [:bz] (still a bit busy) 2002-02-19 09:42:02 PST
Sure, that's what the DOM inspector does.  Too bad the DOM has nothing to do
with the original source, which is what _this_ bug is about.
Comment 211 CoL 2002-02-19 09:49:37 PST
God its worked! :) Why it's not implemented into view source?
Thx Chris!
Comment 212 Sam Rowe 2002-02-19 10:02:51 PST
This javascript is helpful, but doesn't work as advertized... it added some
</tbody> tags to some generated HTML of mine. I don't even know what /tbody
does, and I know it's not in my code.
Comment 213 Matthias Versen [:Matti] 2002-02-19 17:30:12 PST
*** Bug 126521 has been marked as a duplicate of this bug. ***
Comment 214 Jesse Ruderman 2002-02-23 01:50:36 PST
The bookmarklet in comment 209 is called "generated source" and is from
http://www.squarefree.com/bookmarklets/webdevel.html.  I agree with bz and sam
that sometimes the generated source can differ enough from the original source
that it's not as useful, especially if you're trying to debugging a site.  Also,
the bookmarklet doesn't ship with Mozilla, so most users aren't aware of the
workaround.
Comment 215 Matthias Versen [:Matti] 2002-02-25 11:41:06 PST
*** Bug 127644 has been marked as a duplicate of this bug. ***
Comment 216 Sebastian Biallas 2002-02-27 02:30:22 PST
*** Bug 128031 has been marked as a duplicate of this bug. ***
Comment 217 Matthias Versen [:Matti] 2002-02-27 17:06:31 PST
*** Bug 128166 has been marked as a duplicate of this bug. ***
Comment 218 Matthias Versen [:Matti] 2002-02-28 11:49:52 PST
*** Bug 128298 has been marked as a duplicate of this bug. ***
Comment 219 R.K.Aa. 2002-03-01 15:53:07 PST
*** Bug 128529 has been marked as a duplicate of this bug. ***
Comment 220 Adam Katz 2002-03-02 05:38:27 PST
I've added to the javascript in comment 209 and comment 214.
Includes tag coloring, title, and fixed the window to not have interfacing. 
Check it out, it is very nice, even seperates comments and scripts from other
tags.  The second copy is less efficient but parses better.

You can add the following (make it one line first) to your toolbar in the
location section of a bookmark to view-source w/out reloading:

javascript:function htmlEscape(s){s=s.replace(/&/g,'&amp;');
s=s.replace(/>/g,'&gt;');s=s.replace(/</g,'&lt;');s=s.replace(/&lt;/g,'<code>&lt;');
s=s.replace(/<code>&lt;!--/g,'<code class=\"comm\">&lt;!--');
s=s.replace(/&gt;/g,'&gt;<\/code><\/code><\/code>');
s=s.replace(/<code>&lt;script/g,'<span><code style=\"color:blue 
!important\">&lt;script');
s=s.replace(/<code>&lt;\/script/g,'<\/span><code>&lt;/script');return s;} 
x=window.open('','','scrollbars=yes,status=no,location=no,resizable,focus'); 
x.document.write('<html><head>\n<style type=\"text/css\">\n
BODY {color:black;background:#b0b0b8;}\nCODE {color:blue;}\n
CODE CODE {color:black !important;}\n.COMM {color:maroon !important;}\n
PRE>SPAN, SPAN CODE, SPAN .COMM {color:green !important;}\n<\/style>\n
<title>Source of: ' + location.href + '<\/title></head><body><pre>' 
+ htmlEscape('<html>\n' + document.documentElement.innerHTML 
+ '\n<\/pre><\/body><\/html>')); x.document.close();

I know it's a LOT, but it fits on one line (in win2k at least) and works
beautifully.  only regret is the less-thans in javascript handlers like onClick
can only be dealt with by hacking (thus the extra close code tags, special
treatment of script contents, and code's inheritance css rule).

Here's a better looking one (not as tricked by javascript) that colors with a
loop (do NOT use it on longer pages like this one unless you are prepared to WAIT):

javascript:
function hesc(t){t=t.replace(/&/g,'&amp;');
 for(s="";t.length>0;t=t.substring(i,t.length)){
  i=t.indexOf('<',0);if(i<0)i=t.length;s+=t.substring(0,i);
  t=t.substring(i,t.length);
  if(t.substring(1,7)=='script'){i=t.indexOf('>',7);e=t.indexOf('</script>',8);
   s+='<##>&lt;'+t.substring(1,i)+'&gt;<#/#><#code class=scp!>'
    +t.substring(i+1,e)+'<#/#><##>&lt;/script&gt;<#/#>';i=e+9;}
  else if(t.substring(1,4)=='!--'){
   for(i=t.indexOf('-->',0),j=0;j=t.indexOf('<!--',j+1)<i&&j>0;
    i=t.indexOf('-->',i+1));
   s+='<#code class=comm!>&lt;'+t.substring(1,i+=3)+'<#/#>';}
  else {i=t.indexOf('>',1)+1;s+='<##>&lt;'+t.substring(1,i-1)+'&gt;<#/#>';}}
 s=s.replace(/</g,'&lt;').replace(/>/g,'&gt;').replace(/&lt;#/g,'<');
 return s.replace(/#&gt;/g,'code>').replace(/!&gt;/g,'>');} 
x=window.open('','','scrollbars=yes,status=no,location=no,resizable,focus');
x.document.write('<html><head><style type=\'text/css\'>\n
BODY {color:#000;background:#fff}\nCODE {color:#00f}\n
.COMM {color:#800}\n.SCP {color:#080}\n</style>\n<title>Source of: '
+location.href+'</title></head><body><pre>' + hesc('<html>\n'
+document.documentElement.innerHTML+'\n</html>') + '\n</pre></body></html>');
x.document.close();

(sorry for posting so long a comment, I promise not to do this again)
Comment 221 Boris Zbarsky [:bz] (still a bit busy) 2002-03-03 12:30:53 PST
*** Bug 128298 has been marked as a duplicate of this bug. ***
Comment 222 Matthias Versen [:Matti] 2002-03-04 03:29:04 PST
*** Bug 128803 has been marked as a duplicate of this bug. ***
Comment 223 timeless 2002-03-04 06:41:48 PST
please stop spamming this bug with scripts to do dom source viewing. bug 60426 tracks that
Comment 224 Matthias Versen [:Matti] 2002-03-17 10:12:31 PST
*** Bug 131582 has been marked as a duplicate of this bug. ***
Comment 225 rpotts (gone) 2002-03-18 10:10:17 PST
-> rpotts.  my patch to bug #40867 fixes this.
Comment 226 Alfonso Martinez 2002-03-19 06:21:52 PST
*** Bug 131996 has been marked as a duplicate of this bug. ***
Comment 227 Boris Zbarsky [:bz] (still a bit busy) 2002-03-19 20:08:15 PST
*** Bug 132215 has been marked as a duplicate of this bug. ***
Comment 228 Boris Zbarsky [:bz] (still a bit busy) 2002-03-21 11:16:01 PST
*** Bug 132606 has been marked as a duplicate of this bug. ***
Comment 229 Andrew Lin 2002-03-21 17:01:21 PST
*** Bug 132663 has been marked as a duplicate of this bug. ***
Comment 230 Gavin Dodds 2002-03-22 02:20:38 PST
*** Bug 132740 has been marked as a duplicate of this bug. ***
Comment 231 Pascal Bourguignon 2002-03-22 22:46:04 PST
I guess this is the same bug as "Save Frame As..." that will try to fetch the
source again too, and fail with POST results, and otherwise be too much suboptimal.
Comment 232 Vadim Berezniker 2002-03-26 21:34:59 PST
*** Bug 133636 has been marked as a duplicate of this bug. ***
Comment 233 Doron Rosenberg (IBM) 2002-03-28 13:05:41 PST
*** Bug 134024 has been marked as a duplicate of this bug. ***
Comment 234 Matthias Versen [:Matti] 2002-03-29 12:31:19 PST
*** Bug 134272 has been marked as a duplicate of this bug. ***
Comment 235 Olivier Cahagne 2002-04-01 10:03:48 PST
*** Bug 134661 has been marked as a duplicate of this bug. ***
Comment 236 rpotts (gone) 2002-04-01 13:34:56 PST
The patch to bug #40867 has been checked in!!!  So, view-source and
view-frame-source (menu items) should *not* load from the network.

-- rick
Comment 237 Vadim Berezniker 2002-04-01 15:05:22 PST
NOTE: if you're building from source, make sure you delete component.reg before
running mozilla to test this bug. Otherwise it may appear that view-source
doesn't do the expected thing.
Comment 238 Alan Eliasen 2002-04-02 13:44:19 PST
I downloaded the 2002040203 build for windows, deleted component.reg before
running, and I still have problems.  Should I expect to see fixed behavior in
this build?

A few simple cases seemed to work... the source is shown from a POST form
submission that didn't work before.  (But that's a different bug, not this one.)

The first, most obvious problem is that the tags displayed in view-source have
had their case changed.  I use uppercase HTML tags, e.g., <H1>, but the
view-source has changed the case to <h1>.

This bug tracks that the view-source should show, character-for-character, the
exact HTML source emitted by the server so that you can debug problems.

This apparently still needs to be fixed, otherwise view-source still can't be
trusted, and Mozilla can't be used by people developing web applications.
Comment 239 Aaron Kaluszka 2002-04-02 13:55:23 PST
What you're referring to is bug 57724.
Comment 240 Martin Dougiamas 2002-04-03 03:17:13 PST
Should View Source work on this page? 
http://bugzilla.mozilla.org/buglist.cgi?bug_id=55583
It doesn't for me using 2002040203 on Win XP - I get a download dialog instead.
Comment 241 Martin Dougiamas 2002-04-03 03:19:03 PST
Should View Source work on this page? 
http://bugzilla.mozilla.org/buglist.cgi?bug_id=55583
It doesn't for me using 2002040203 on Win XP - I get a download dialog instead.
Comment 242 Gilles Durys 2002-04-03 03:32:49 PST
Martin, what you're seeing is bug 76816
Comment 243 Robert Jirik 2002-04-04 11:06:11 PST
The bug seems not to be fixed for me ...
Got 2002040403, when trying to view some page, which posted data via POST method
(typically new guestbook entry), it asks me, whether I want to post data again:
- no: nothing shows (possibly ok)
- yes: shows not the source, but the page (the same page as in the main browser
window), but in view-source window
With 20020402xx it didn't work either (it didn't show *any* source in *any* case
in fact), where is the problem?

running win2k, today's nightly with talkback
Comment 244 Sören 'Chucker' Kuklau (gone) 2002-04-04 11:12:01 PST
#243
Could you please specify the URL you've been testing?
Comment 245 Robert Jirik 2002-04-05 06:37:13 PST
Yes of course ...
If you don't mind reading a bit Czech, try to look @
http://isil.xhaven.net/_private/etheniel/gbook.php ... Press the blue button, on
which is something like `~ novy prispevek ~`.
The page should change, and there should be title like `Kniha navstev (\n)
Pridani noveho prispevku` (and below some input lines.
Try to view source there - I see the page like in the browser window
(everytime). Yesterday, I tried it here on bugzilla, when I posted the article,
someone else did, and therefore there was a `mid-air collision`, or how is it
called. I tried viewing the source, and saw the same bug again ...

By the way - why does Mozilla ask me, whether I want to download something after
processing a search query from the main page (bugzilla.mozilla.org)?
The view-source window appears, and then `Downloading buglist.cgi - You have
chosen ...... of type multipart/x-mixed-replace;x-view-type=view-source from
http://bugzilla.mozilla.org/??

build 2002040403
Comment 246 Vadim Berezniker 2002-04-05 06:52:17 PST
Robert, I tried that page and what I see in view-source is what I expect to see.

As for the other problem, it was mentioned right before your first comment.
It's bug 76816
Comment 247 Leston Buell 2002-04-05 06:54:12 PST
Robert, Which version (including platform: Windows? Linux? Mac?) do you see this
bug in for the xhaven page? I'm using Linux trunk build 2002-04-04-10 and i when
i do view source i actually see the source, not the page as rendered in the
browser window. 
Comment 248 Robert Jirik 2002-04-05 09:28:25 PST
Created attachment 77859 [details]
etheniel homepage bug

The bug viewed in http://isil.xhaven.net/_private/etheniel/gbook.php
Comment 249 Robert Jirik 2002-04-05 09:32:26 PST
Well, I downloaded today's nightly (2002-04-05-03) and I regret to say, that it
is pretty the same.

My configuration:
Win2k czech
2002-04-05-03

Couldn't the problem be in my Czech system? Can anyone prove that?

You can see exactly what do I see in the attachment ...
Comment 250 Boris Zbarsky [:bz] (still a bit busy) 2002-04-05 10:43:29 PST
Robert, this probably depends on your cache settings. With this bug fixed
view-source now reads from the cache.  The document seems to immediately expire
from your cache (is it sent as no-store or something?).

Please file a separate bug on the screwup that happens when you say to resend
the data and post the bug number here.
Comment 251 Robert Jirik 2002-04-05 13:32:14 PST
Boris, you were absolutely right. My disk && memory cache was disabled (set to 0
kB) because of some proxy problems some time ago.
Reenabling the cache solved the problem.
Should this really be called `a bug`? Gonna send you e-mail, don't want to
bother 250 people anymore ...
Comment 252 Dennis Haney 2002-04-05 13:54:26 PST
You should file a bug about the lack of a warning that mozilla is unable to
perform the task correctly!
Comment 253 Robert Jirik 2002-04-05 15:14:51 PST
OK, filed bug #135833, http://bugzilla.mozilla.org/show_bug.cgi?id=135833
Comment 254 Christopher Aillon (sabbatical, not receiving bugmail) 2002-04-14 09:14:17 PDT
*** Bug 137397 has been marked as a duplicate of this bug. ***
Comment 255 R.K.Aa. 2002-04-14 23:54:11 PDT
*** Bug 137479 has been marked as a duplicate of this bug. ***
Comment 256 Boris Zbarsky [:bz] (still a bit busy) 2002-04-19 10:14:58 PDT
*** Bug 138534 has been marked as a duplicate of this bug. ***
Comment 257 Boris 'pi' Piwinger 2002-04-24 08:26:43 PDT
*** Bug 139754 has been marked as a duplicate of this bug. ***
Comment 258 Boris 'pi' Piwinger 2002-05-15 12:33:32 PDT
*** Bug 144794 has been marked as a duplicate of this bug. ***
Comment 259 Boris Zbarsky [:bz] (still a bit busy) 2002-06-06 11:09:20 PDT
*** Bug 148072 has been marked as a duplicate of this bug. ***
Comment 260 Philip White 2002-06-06 13:06:17 PDT
*** Bug 137204 has been marked as a duplicate of this bug. ***
Comment 261 Stephan Jaensch 2002-06-14 15:35:30 PDT
v
Comment 262 Tuukka Tolvanen (sp3000) 2002-08-11 14:32:10 PDT
*** Bug 162211 has been marked as a duplicate of this bug. ***
Comment 263 Frank Widmaier 2002-09-10 14:54:41 PDT
OK.. now someone gave me that bug-number (I first posted at a "wrong" number -
bug 57724)

1.2a, 20020907, MultiZilla/v1.1.22

when using view-source on php-pages, you get a to "standard-values" resettet
sourcecode. Post data, that you got from forms (process it and get results (eg
sql)), won't be resend with a call for the source of the page. Makes
html-troubleshooting a little bit complicated ;-).

I think the bug should be reopened
Comment 264 Boris Zbarsky [:bz] (still a bit busy) 2002-09-10 19:33:54 PDT
Frank, are you using multizilla's "view-source in a tab" feature?  If so,
they're just doing it wrong.  Hence the problem.
Comment 265 HJ 2002-09-11 00:37:04 PDT
The view-source bug in MultiZilla is already fixed. I just forgot to commit my
changes in our cvs tree, so Raj (our webmaster) did a commit for me, but he
didn't had the latest update of multiviewsOverlay.js.

FYI: I'm not at home but visiting my father so that is why I couldn't do a cvs
commit (:
Comment 266 Nick Bebout 2002-12-03 18:57:16 PST
This bug appears to still be occuring for me on Build ID: 2002120108 on Windows
XP Home Edition
therefore.
Comment 267 Boris Zbarsky [:bz] (still a bit busy) 2002-12-03 19:04:41 PST
1)  Steps to reproduce please?  Those are kinda needed to do anything, you know.
    I can't repro the problem with any of the testcases I wrote for this bug
    originally.
2)  File a _new_ bug on the View Source component.  cc me.  This bug is fixed.
    Even if the symptoms are the same, the underlying problem is separate.
Comment 268 Michael Lefevre 2003-04-11 06:21:04 PDT
re-verifying
Comment 269 Daniel Kabs, reporting bugs since 2002 2003-07-08 08:57:56 PDT
Using Milestone Release 1.4 on Windows 2000, Mozilla does not use the
cached source but asks for submitting the POST data again.

Want to try yourself?

Go to 

http://democam.mobotixserver.de/cgi-bin/store2rom

press the button, wait for the page to return and then do
right-click -> View Page Source.
Now a popup window will appear telling you that the "page you are trying
to view contains POSTDATA that has expired from cache".

As a web developer I found this behavior very awkward as you don't get
to see the HTML source of the original POST request. You have to submit
the request again. That may result in a completely different page as
the web pages are created dynamically.


Should I file a new bug?
Comment 270 Arthur 2003-07-08 09:07:31 PDT
Huh? Can't reproduce this on 1.4 under linux. And yes, file a new bug if this is
reproducable.
Comment 271 Daniel Kabs, reporting bugs since 2002 2003-07-08 09:39:31 PDT
Arthur,

I just tried the URL on Linux using Mozilla 1.3 (Gecko/20030312) and the 
pop up window does *not* appear. Maybe the bug is related to the Windows
version only?

Here is another URL to check out:
- Open http://www.theregister.co.uk
- Enter something in the text box and press Go!
- View Page Source.

That page includes a timestamp that is updated every minute. So at least
on Windows I get a different source view every minute.

But maybe that problem is already coverd by bug 57724 ? 
Comment 272 Rajendra Shrestha 2003-07-08 09:49:27 PDT
I can NOT reproduce this in Mozilla 1.4/Windows 2000. I do NOT get the pop up
message and the view source correctly shows source for what is displayed. Make
sure your cache settings are fine.
Comment 273 Robert Jirik 2003-07-08 09:59:34 PDT
No troubles with 1.4final on Linux - as far as I remember 1.3 was OK as well ...
could be Windows-only problem although I doubt it (since I use Windows with
Mozilla sometimes and haven't encountered this bug for some time) ...
Comment 274 Daniel Kabs, reporting bugs since 2002 2003-07-08 10:12:48 PDT
You are right, I just installed Mozilla1.4 on a second W2k computer and it
does not display the "POST resend request". So it has to do with my special
setup.

Mh, my Advanced -> Cache settings are the same as on the other computer:
50 MB Cache size and "when the page is out of date".
about:config says that browser.cache.disk.enable is true.

The difference is that I am using a proxy on the computer where the popup
appears. The HTTP Header from the page that comes from the proxy looks like:

HTTP/1.0 200 OK
Content-Type: text/html
Cache-Control: no-cache
X-Cache: MISS from firewall.mobotix.net
Proxy-Connection: close

Pitty, I can't sniff the HTTP data on the other computer where everything
works ok.
Comment 275 Boris Zbarsky [:bz] (still a bit busy) 2003-07-08 10:43:39 PDT
That dialog about POST data is what you get when Mozilla no longer has the
original source for the page -- in particular, when that source has expired from
cache.  There's a bug report somewhere about holding on to the source in some
special form outside the cache to prevent this from happening....
Comment 276 Dimitrios 2003-07-08 12:43:01 PDT
bug 91875 ?
Comment 277 Boris Zbarsky [:bz] (still a bit busy) 2003-07-08 12:50:54 PDT
No.  Bug 166786
Comment 278 Daniel Kabs, reporting bugs since 2002 2003-07-08 14:24:55 PDT
Boris, so the proxy (Squid) is adding these HTTP headers which make
Mozilla "forget" the pages and thus the source code? I have to 
try and compare these headers with those on a direct connection.
Comment 279 Daniel Kabs, reporting bugs since 2002 2003-07-09 04:50:18 PDT
I finally figured, it is not the proxy. I did a clean install of Mozilla 1.4 and
now it works as it should. No more pop ups asking for resending POSTDATA. See
Bug 166786.
Sorry for wasting your bandwidth.
Comment 280 mozilla 2008-12-16 19:24:45 PST
For any page which is visible, "Save As", "Print", "View Source", "Open Frame In New Tab" and similar functions should never, under any circumstance, open a network connection.  The viewed pages must be stored raw in RAM or disk cache, any other method is faulty.  HTTP headers or meta tags specifying not to cache a page should have no bearing on the user's ability to use the currently viewed page(s).

How is this not completely obvious, and how could the developers ever think that doing it any other way could possibly be considered "better"?

Only in Gecko browsers can a person on dial-up spend 45 minutes downloading a 4.5MB JPEG file, right-click and select Save As, followed by the browser redownloading the image again!  No other browser does such stupid things.
Comment 281 Taral 2008-12-17 11:19:55 PST
I have to agree here. We have far too many stupid servers blindly setting Cache-Control or Pragme: no-cache to be dumb about following those instructions. Items that are expired should not be removed from the cache until they are no longer "referenced" e.g. by windows/tabs.

Recommend REOPEN.
Comment 282 mozilla 2008-12-17 17:03:28 PST
Bug 288462 provides the full summary of all related issues, complete with RFC violations.  Should be linked to this one.
Comment 283 Boris Zbarsky [:bz] (still a bit busy) 2008-12-18 15:17:27 PST
Taral, this bug fixed the no-cache behavior.  That was the whole point of this bug.  At this point entry expiration for view-source purposes does not depend on anything the _server_ does.  It only happens on cache collisions or cache getting full.

Of course you could have checked this trivially yourself instead of sending content-less mail to dozens of people....
Comment 284 Boris Zbarsky [:bz] (still a bit busy) 2008-12-18 18:29:04 PST
I'd like to apologize to Taral, since I'm guessing that he's testing this in a recent Firefox build.  Those builds recently introduced a bug in Firefox's view-source window (unlike this bug, which was a bug in the core code) that causes said view-source window to not use the codepath this bug added.

I filed bug 470357 on the issue.  In general, that's the right course of action when issues seem to reappear: reopening a long-resolved bug is not the right way to get eyes on them.  We have a "regression" keyword to track such problems.

Note You need to log in before you can comment on or make changes to this bug.