Closed Bug 55583 Opened 24 years ago Closed 22 years ago

view-source should show original page source (use cached source)

Categories

(Core :: DOM: Navigation, defect, P2)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: law, Assigned: rpotts)

References

(
URL
)

Details

(4 keywords, Whiteboard: [Hixie-P1] (HTTP) blocked by 40867 [bug timeless for wysiwyg:// pseudo support] relnote-user)

Attachments

(1 file)

etheniel homepage bug
112.93 KB, image/jpeg
Details 
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.
Won't this be fixed by bug 40867 anyway?
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.

*** Bug 56861 has been marked as a duplicate of this bug. ***
*** Bug 56575 has been marked as a duplicate of this bug. ***
Blocks: 57724
*** Bug 57846 has been marked as a duplicate of this bug. ***
OS: other → All
Whiteboard: relnote-user
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?
*** Bug 58703 has been marked as a duplicate of this bug. ***
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.)

Marking as depending on bug 40867.
Depends on: 40867
*** Bug 59642 has been marked as a duplicate of this bug. ***
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>
Assignee: law → timeless
Keywords: helpwanted, mozilla0.9, mozilla1.0
Priority: P3 → P2
Whiteboard: relnote-user → [bug timeless for patch]relnote-user
Target Milestone: --- → mozilla1.0
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).
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.

Ok ->Networking:Cache.
Assignee: timeless → neeti
Component: XP Apps → Networking: Cache
QA Contact: sairuh → tever
Summary: view-source doesn't work for pages generated via forms with method=POST → view-source should pull from cache. [doesn't work for pages generated via forms with method=POST]
Whiteboard: [bug timeless for patch]relnote-user → [bug timeless for wysiwyg:// pseudo support]relnote-user
*** Bug 61325 has been marked as a duplicate of this bug. ***
Viewing generated source is now bug 60426.
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.
*** Bug 62746 has been marked as a duplicate of this bug. ***
*** Bug 57749 has been marked as a duplicate of this bug. ***
*** Bug 62746 has been marked as a duplicate of this bug. ***
hmm, I think this should get into mostfreq list when looking at all that dupes...
Keywords: mostfreq
*** Bug 63589 has been marked as a duplicate of this bug. ***
*** Bug 63598 has been marked as a duplicate of this bug. ***
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.
Severity: normal → major
Summary: view-source should pull from cache. [doesn't work for pages generated via forms with method=POST] → view-source should pull from cache
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.)
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.
Keywords: arch
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...)
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.
Summary: view-source should pull from cache → view-source should show original source
> 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.

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.
Summary: view-source should show original source → view-source should pull from cache
updating summary
Summary: view-source should pull from cache → view-source should show original source
Whiteboard: [bug timeless for wysiwyg:// pseudo support]relnote-user → blocked by 40867 [bug timeless for wysiwyg:// pseudo support]relnote-user
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?)
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.
Adding self to CC, and agreeing vigorously with Deven.

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?
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.
law made his call.
Depends on: 64100
No longer depends on: 64100
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...
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.
> 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.

> > 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?


> > 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?
both.
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...)
*** Bug 64901 has been marked as a duplicate of this bug. ***
add myself to cc
*** Bug 65601 has been marked as a duplicate of this bug. ***
*** Bug 65788 has been marked as a duplicate of this bug. ***
this might be fixed if 66334 gets fixed.
*** Bug 66993 has been marked as a duplicate of this bug. ***
*** Bug 67534 has been marked as a duplicate of this bug. ***
*** Bug 68588 has been marked as a duplicate of this bug. ***
Cache bugs to Gordon
Assignee: neeti → gordon
*** Bug 71251 has been marked as a duplicate of this bug. ***
*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 :(
Reminder: there's a lot of relevant discussion under bug 56346 and bug 40867...
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......
*** Bug 77863 has been marked as a duplicate of this bug. ***
*** Bug 78086 has been marked as a duplicate of this bug. ***
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.
Assignee: gordon → chak
Cc:ing Boris for his insight since he's been working on a lot of viewsource: 
related issues.
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.
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.
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!
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.
back to gordon. all chak did was change view-source from being a "mode" to a 
"protocol handler".
Assignee: chak → gordon
So why should I get this bug?  Gagan, can you find the owner for view-source?
Assignee: gordon → gagan
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?

in that case ->law and law: check with darin on the cache flags to use
Assignee: gagan → law
*** Bug 80989 has been marked as a duplicate of this bug. ***
*** Bug 81913 has been marked as a duplicate of this bug. ***
Adding "(use cached source)" to summary to make this bug more re-findable.
Keywords: dataloss
Summary: view-source should show original source → view-source should show original source (use cached source)
*** Bug 81403 has been marked as a duplicate of this bug. ***
nav triage team:

Not a beta stopper, marking nsbeta1-. The helpwanted keyword is still there. ;-)
Keywords: nsbeta1-
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.
*** Bug 82489 has been marked as a duplicate of this bug. ***
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.
Keywords: nsbeta1-, relnoteRTM → nsbeta1
*** Bug 81531 has been marked as a duplicate of this bug. ***
*** Bug 81531 has been marked as a duplicate of this bug. ***
Copying correctness and highrisk keywords from bug 40867 - they are equally
applicable here.
Keywords: correctness, highrisk
*** Bug 83122 has been marked as a duplicate of this bug. ***
*** Bug 83221 has been marked as a duplicate of this bug. ***
Whiteboard: blocked by 40867 [bug timeless for wysiwyg:// pseudo support]relnote-user → [Hixie-P1] (HTTP) blocked by 40867 [bug timeless for wysiwyg:// pseudo support] relnote-user
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!
Keywords: nsbeta1 → nsbeta1-
*** Bug 84684 has been marked as a duplicate of this bug. ***
*** Bug 85398 has been marked as a duplicate of this bug. ***
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.
*** Bug 74834 has been marked as a duplicate of this bug. ***
Blocks: 79518
Blocks: 86835
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?
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...
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 :)
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...


*** Bug 90203 has been marked as a duplicate of this bug. ***
*** Bug 80301 has been marked as a duplicate of this bug. ***
*** Bug 84393 has been marked as a duplicate of this bug. ***
*** Bug 91456 has been marked as a duplicate of this bug. ***
No longer blocks: 57724
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.

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.
Depends on: 90722
*** Bug 95149 has been marked as a duplicate of this bug. ***
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.
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.)
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.
Depends on: 99107
*** Bug 99449 has been marked as a duplicate of this bug. ***
*** Bug 99971 has been marked as a duplicate of this bug. ***
*** Bug 100529 has been marked as a duplicate of this bug. ***
*** Bug 100728 has been marked as a duplicate of this bug. ***
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.

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.
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.
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?


<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>
> 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.
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.
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...
> > 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.
> 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.


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?
> 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...








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.
> 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....


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.
> 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.


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.
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.
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...
> 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.
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.
How does Netscape 4.7 handle view source?
Could the same be done here?

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).

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.
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
*** Bug 100939 has been marked as a duplicate of this bug. ***
Blocks: 98995
*** Bug 102499 has been marked as a duplicate of this bug. ***
*** Bug 104607 has been marked as a duplicate of this bug. ***
*** Bug 105554 has been marked as a duplicate of this bug. ***
*** Bug 105683 has been marked as a duplicate of this bug. ***
*** Bug 106230 has been marked as a duplicate of this bug. ***
*** Bug 107948 has been marked as a duplicate of this bug. ***
*** Bug 64100 has been marked as a duplicate of this bug. ***
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
*** Bug 110489 has been marked as a duplicate of this bug. ***
*** Bug 110717 has been marked as a duplicate of this bug. ***
*** Bug 110827 has been marked as a duplicate of this bug. ***
->mozilla0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9
*** Bug 110959 has been marked as a duplicate of this bug. ***
*** Bug 110864 has been marked as a duplicate of this bug. ***
*** Bug 111466 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
*** Bug 113304 has been marked as a duplicate of this bug. ***
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...


*** Bug 115059 has been marked as a duplicate of this bug. ***
*** Bug 116070 has been marked as a duplicate of this bug. ***
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.
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) ?
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).
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.

*** Bug 117197 has been marked as a duplicate of this bug. ***
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.

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?
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.
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".
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
<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>
*** Bug 117391 has been marked as a duplicate of this bug. ***
*** Bug 117634 has been marked as a duplicate of this bug. ***
Modifying summary to include the phrase "page source," per request.
Summary: view-source should show original source (use cached source) → view-source should show original page source (use cached source)
*** Bug 118536 has been marked as a duplicate of this bug. ***
*** Bug 118562 has been marked as a duplicate of this bug. ***
*** Bug 119008 has been marked as a duplicate of this bug. ***
*** Bug 119802 has been marked as a duplicate of this bug. ***
*** Bug 120804 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 40867 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
vrfy
Status: RESOLVED → VERIFIED
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.
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.
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.
> 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... :-(
Reopening as per comments by Ben Bucksch in comment 176, to avoid problems with
lost votes, dupe count, and dependency tree.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
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.
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.
Assignee: law → adamlock
Status: REOPENED → NEW
Component: Networking: Cache → Embedding: Docshell
QA Contact: tever → adamlock
Target Milestone: mozilla0.9.9 → ---
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.
Target Milestone: --- → Future
*** Bug 121436 has been marked as a duplicate of this bug. ***
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.

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?
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]
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?


> 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.

>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... 
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.


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?


Why can't your throw the cached item into a temp file and open it up in the
viewer window?
> 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.
> 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.
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.
> 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.
CC'ing Gordon & Radha for ideas how to pull this data out of cache
Keywords: nsbeta1 → nsbeta1-
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.
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++
People, this bug is not for bitching/complaining, we've got newsgroups for that.
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.
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. 
*** Bug 123166 has been marked as a duplicate of this bug. ***
*** Bug 124509 has been marked as a duplicate of this bug. ***
*** Bug 125095 has been marked as a duplicate of this bug. ***
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.

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.
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).
*** Bug 125866 has been marked as a duplicate of this bug. ***
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.
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();
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.
God its worked! :) Why it's not implemented into view source?
Thx Chris!
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.
*** Bug 126521 has been marked as a duplicate of this bug. ***
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.
*** Bug 127644 has been marked as a duplicate of this bug. ***
*** Bug 128031 has been marked as a duplicate of this bug. ***
*** Bug 128166 has been marked as a duplicate of this bug. ***
*** Bug 128298 has been marked as a duplicate of this bug. ***
*** Bug 128529 has been marked as a duplicate of this bug. ***
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)
*** Bug 128298 has been marked as a duplicate of this bug. ***
*** Bug 128803 has been marked as a duplicate of this bug. ***
please stop spamming this bug with scripts to do dom source viewing. bug 60426 tracks that
*** Bug 131582 has been marked as a duplicate of this bug. ***
-> rpotts.  my patch to bug #40867 fixes this.
Assignee: adamlock → rpotts
*** Bug 131996 has been marked as a duplicate of this bug. ***
*** Bug 132215 has been marked as a duplicate of this bug. ***
*** Bug 132606 has been marked as a duplicate of this bug. ***
*** Bug 132663 has been marked as a duplicate of this bug. ***
*** Bug 132740 has been marked as a duplicate of this bug. ***
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.

*** Bug 133636 has been marked as a duplicate of this bug. ***
*** Bug 134024 has been marked as a duplicate of this bug. ***
*** Bug 134272 has been marked as a duplicate of this bug. ***
*** Bug 134661 has been marked as a duplicate of this bug. ***
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
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
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.
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.
What you're referring to is bug 57724.
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.
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.
Martin, what you're seeing is bug 76816
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
#243
Could you please specify the URL you've been testing?
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
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
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. 
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 ...
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.
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 ...
You should file a bug about the lack of a warning that mozilla is unable to
perform the task correctly!
*** Bug 137397 has been marked as a duplicate of this bug. ***
*** Bug 137479 has been marked as a duplicate of this bug. ***
*** Bug 138534 has been marked as a duplicate of this bug. ***
*** Bug 139754 has been marked as a duplicate of this bug. ***
*** Bug 144794 has been marked as a duplicate of this bug. ***
*** Bug 148072 has been marked as a duplicate of this bug. ***
*** Bug 137204 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
v
*** Bug 162211 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
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
Frank, are you using multizilla's "view-source in a tab" feature?  If so,
they're just doing it wrong.  Hence the problem.
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 (:
This bug appears to still be occuring for me on Build ID: 2002120108 on Windows
XP Home Edition
therefore.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
re-verifying
Status: RESOLVED → VERIFIED
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?
Huh? Can't reproduce this on 1.4 under linux. And yes, file a new bug if this is
reproducable.
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 ? 
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.
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) ...
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.
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....
bug 91875 ?
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.
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.
No longer blocks: majorbugs
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.
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.
Bug 288462 provides the full summary of all related issues, complete with RFC violations.  Should be linked to this one.
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....
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.

hi, in the recent update, i still have the same bug.

firefox display the source code from the Reffering URL, no from the current read page !

This bug describes an issue fixed almost 20 years ago. If you are experiencing an issue with view source now, please file a new bug. Commenting here just confuses things and will likely not lead to your issue being fixed.

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

Attachment

General

Creator:
Created:
Updated:
Size: