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 → 23 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: 23 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: