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)
Core
DOM: Navigation
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: law, Assigned: rpotts)
References
()
Details
(4 keywords, Whiteboard: [Hixie-P1] (HTTP) blocked by 40867 [bug timeless for wysiwyg:// pseudo support] relnote-user)
Attachments
(1 file)
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.
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.
Updated•24 years ago
|
Keywords: relnoteRTM
Updated•24 years ago
|
OS: other → All
Updated•24 years ago
|
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?
An idiosyncracy of a URL I experience this on is not just that the page is dynamically generated from a post, but that the form tag has no action attribute, so that submitting the form goes back to the same URL, which then returns a different page. But view source shows the first page's source. (The URL I experienced this on is on an internal development site that's only intermittently available outside of our network, if at all. If you want to see it, I can probably make an instance of it available.)
Comment 10•24 years ago
|
||
*** Bug 59642 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
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
Priority: P3 → P2
Whiteboard: relnote-user → [bug timeless for patch]relnote-user
Target Milestone: --- → mozilla1.0
Comment 12•24 years ago
|
||
I think, the current page source is nice, but is no substitution for the normal view source. The latter is e.g. useful to track bugs in the page, and the former could hide evil content (e.g. an evil script which at the end overrides its own source with something harmless).
Comment 13•24 years ago
|
||
Timeless, I think what you are implementing with original vs. DOM source is cool, but completely unrelated to this bug, and the dependency on bug 40867 is entirely appropriate. It is quite possible that a form submission (like any other page) could contain stuff which manipulates the DOM, but a user should always be able to see the original source of the page as well.
Comment 14•24 years ago
|
||
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
Comment 15•24 years ago
|
||
*** Bug 61325 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
Viewing generated source is now bug 60426.
Comment 17•24 years ago
|
||
Adding CC to self I have been building and using mozilla from the cvs trunk, and have been annoyed by this particular bug. I develop servlets for my employer, and would like to be able to view what comes back from MyServlet.doPost() in mozilla. I always end up seeing what is generated by MyServlet.doGet() instead, making me open Netscape 4.xx -- yuck.
Comment 18•24 years ago
|
||
*** Bug 62746 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
*** Bug 57749 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
*** Bug 62746 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
hmm, I think this should get into mostfreq list when looking at all that dupes...
Keywords: mostfreq
Comment 22•24 years ago
|
||
*** Bug 63589 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
*** Bug 63598 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
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
Comment 25•24 years ago
|
||
I would suggest a more accurate summary of "view-source should show the original source" since pulling from the cache is sometimes what causes the results to be wrong! (See comments under bug 6119 for details.)
Comment 26•24 years ago
|
||
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
Comment 27•24 years ago
|
||
This would be better discussed under bug 40867, where the architectural issues have been raised, and would fix that bug, this one, and several others. That said, bug 56346 is worth checking out, because it has a quote from RFC 2616 describing how and why history mechanisms should be be different from caches. Now, I don't know if "history objects" should get nscomptrs (which I'm assuming is a reference-counted pointer?), but it seems clear that they should have a unique reference of some sort. However, nothing precludes that unique reference from representing history data stored on disk; it's not strictly necessary to store it in VM. And if there's no hope of storing the page in either memory or on disk, there could be a dialog box a la NN4's warning about re-posting form data. At least the user would know when the original data had been lost. (Maybe it should require confirmation before discarding the old data? Maybe it should never discard data for the currently-viewed page of any open window?) As for your 900MB testcase, is that mostly the source or the constructed DOM? If it's mostly the DOM, would it be feasible to save the source, reconstruct the DOM when returning to the page, then (somehow) apply any changes that were made to the DOM previously? (By the way, what sort of testcase uses such an enormous amount of VM to load?) Regarding the competition, shouldn't we aim for doing the "right" thing, whether or not the competition does? (Presuming, of course, that the "right" thing will inherently be at least as good as whatever the competition does...)
Comment 28•24 years ago
|
||
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
Comment 29•24 years ago
|
||
> I remember somebody saying BTW: It was not a Mozilla developer, so take that info with caution. > which I'm assuming is a reference-counted pointer? Yes.
Comment 30•24 years ago
|
||
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
Comment 31•24 years ago
|
||
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
Comment 32•24 years ago
|
||
I think a lot of people have a good idea of what the right thing is, which is why there's so many duplicate bugs reported of behavior that isn't quite right! On the other hand, I guess it's ambiguous enough to require some debate... I guess I'm something of a purist when it comes to something like "view source". I really do want to see *exactly* what the browser received, even if that source contained 10,000,000 spaces that were semantically equivalent to one. While it seems unexpected to see so many spaces, let's imagine that it really is happening, perhaps because of a dynamic content engine malfunctioning (or at least, being inefficient). If I (as the user) have waited for megabytes of information to come over the wire, and then "view source" shows me one page of source, I'm going to think there's something fishy going on. If I see the exact source, I may be surprised at such a plethora of spaces, but I'll immediately look to the content being generated and NOT suspect the browser of misleading me. Those 10,000,000 spaces may mean nothing to the browser, but they might be significant to me, or at least it would be confusing to have them elided without warning... (Now, having an *option* to elide meaningless data would be valuable, for users who are wanting and expecting such a feature...) Considering both the RFC quote and common sense, it seems most "right" to have any "history" functions (back/forward, view-source, save-as, etc.) to operate with exactly the same data as before, regardless of the size or state of the cache, and regardless of what content changes may have occurred on the server. And yes, logically this even applies to image data, despite the size. Nothing stops us from writing the information out to disk until it's needed, since we can be sure that we'll be reloading the original data from disk. (Also, we could compress the data with zlib, to save disk or memory space, at a CPU cost.) The obvious danger is that saving too much leads to "bloat". On the other hand, when there's enough memory to do it, it is a big performance win. The tradeoffs involved should probably be left up to the user, don't you think? (What do you think of the idea of a separated cache manager as I suggested in bug 40867?)
Comment 33•24 years ago
|
||
I agree with Deven. I want to see *exactly* what the server sent, without headers. I don't know how an author could "hide" code, given that scrollbars will appear. I can always use an external reformatter, if the code has been obfuscated.
Comment 34•24 years ago
|
||
Adding self to CC, and agreeing vigorously with Deven.
Reporter | ||
Comment 35•24 years ago
|
||
Darn it. I opened this bug for a very specific reason. The view source code does not handle URLs with form post data. What the hell happened?
Comment 36•24 years ago
|
||
law, your call, how we track the other problems. But, as pointed out, there *are* remaining problems apart from POST. And they are just as urgent as POST.
Comment 38•24 years ago
|
||
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...
Reporter | ||
Comment 39•24 years ago
|
||
40867 might well need to be fixed and doing so might make it easy to fix some of the more subtle view-source quirks. But it is distinct from the problem I raised with this bug initially (and with my new bug, whose number must remain top secret :-). The code in viewsource.js has to step up to deal with form post data in some respect, otherwise, you are unlikely to be able to reliable fetch the data from anywhere. The reason is that the URL by itself is insufficient to uniquely identify the source. For example, you might have two windows that show distinct form submission results from the same URL. So I think this bug needs to be fixed independent of other work on some pseudo-cache that holds source for current content. When such a facility is online, viewsource.js can be modified to pass whatever is necessary to get the proper source from that facility. I really want a separate bug because then we might have a chance to fix the problem for the majority of cases (i.e., the source is actually in the cache) even if we don't fix 40867. I wouldn't bet money on 40867 getting fixed by Mozilla 1.0.
Comment 40•24 years ago
|
||
> So I think this bug needs to be fixed independent of other work on some > pseudo-cache that holds source for current content. I see. So, it was actually wrong to widen the scope of this bug. Sorry. I should have reopened the other one. Too late. > I wouldn't bet money on 40867 getting fixed by Mozilla 1.0. IMO, this bug is a Mozilla 1.0 must-fix.
Comment 41•24 years ago
|
||
> > I wouldn't bet money on 40867 getting fixed by Mozilla 1.0. > > IMO, this bug is a Mozilla 1.0 must-fix. I feel moved to agree with this comment. I think Mozilla-the-platform needs happy developers who can use Mozilla-the-browser to view the output of their cgi/php/servlet pages. Or have the platform ambitions waned a bit?
Comment 42•24 years ago
|
||
> > I wouldn't bet money on 40867 getting fixed by Mozilla 1.0. > > IMO, this bug is a Mozilla 1.0 must-fix. Just to be clear, does "this bug" refer to bug 55583 or bug 40867?
Comment 43•24 years ago
|
||
both.
Comment 44•24 years ago
|
||
Okay. I've already mentioned under bug 40867 that I'm willing to work on that bug unless and until someone else comes along to work on it that can make a stronger commitment to delivering a fix. (I may not deliver anything, but I'd rather work on it anyway, if nobody else is ready to work on it yet...)
Comment 45•24 years ago
|
||
*** Bug 64901 has been marked as a duplicate of this bug. ***
Comment 46•24 years ago
|
||
add myself to cc
Comment 47•24 years ago
|
||
*** Bug 65601 has been marked as a duplicate of this bug. ***
Comment 48•24 years ago
|
||
*** Bug 65788 has been marked as a duplicate of this bug. ***
Comment 49•24 years ago
|
||
this might be fixed if 66334 gets fixed.
Comment 50•24 years ago
|
||
*** Bug 66993 has been marked as a duplicate of this bug. ***
Comment 51•24 years ago
|
||
*** Bug 67534 has been marked as a duplicate of this bug. ***
Comment 52•23 years ago
|
||
*** Bug 68588 has been marked as a duplicate of this bug. ***
Comment 54•23 years ago
|
||
*** Bug 71251 has been marked as a duplicate of this bug. ***
Comment 55•23 years ago
|
||
*adding self to CC list* If view-source doesnt show me EXACTLY byte-for-byte what it downloaded from the server (WITHOUT re-requesting it) then view source is utterly useless to me :(
Comment 56•23 years ago
|
||
Reminder: there's a lot of relevant discussion under bug 56346 and bug 40867...
Comment 57•23 years ago
|
||
Must say the discussion between Bug 56346, Bug 55583, and Bug 40876 if nothing else is impressive. As a web app developer I would have to agree with Deven, in that this bug needs to be fixed in the right way rather than the easy/fast way. I also noticed that in all of the discussion of Get/Post on this particular bug as well as the other 2 mentioned above, and with the discussion of XML/XUL/etc. on the history of Bug 40876, no one mentioned Cookies. For instance I am developing a series of applications that have many functions in one script (aka, the same url) but that also check/set cookies to vary the content of those pages (I am not stating that is impressive, actually I am thinking it is very common), which also means it adds another level of complexity when it comes to the idea of storing the page in the cache. It is one thing to store the base url, the POST/GET parts, the browser window, but are you also going to store the state of every one of the cookies that is available to that series of domains??? I think Deven was initially correct in stating that while storing the page(s) in memory may be memory intense, it is overally complex to store the necessary attributes in either cache (or regenerating from DOM, see other bug discussions (which I think was nixed)) and will eventually be less than perfect when re-representing the page to the end user, be they browsing, purchasing, developing, etc. Thanks to the developers, and everyone that has put their time and hearts into it......
Comment 58•23 years ago
|
||
*** Bug 77863 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
*** Bug 78086 has been marked as a duplicate of this bug. ***
Comment 60•23 years ago
|
||
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
Comment 61•23 years ago
|
||
Cc:ing Boris for his insight since he's been working on a lot of viewsource: related issues.
Comment 62•23 years ago
|
||
In Mozilla .9, "view frame source" makes another trip to the webserver (I record it in a debug log that I keep on the server), only without the POST data (regardless of cache settings). Obviously, this happens in NN6.01 too. Since I am using POST and a hidden frame for proprietary purposes, this can be quite maddening (ie: when I unhide the frame and view the source). If you need a test case, let me know and I'll hammer one together, but it looks to me like you already have plenty of information on this issue. I confess I speed-read this bug's history, so forgive me if I've gotten the wrong idea: It appears to me that under some circumstances, making another trip to the server, indeed, another POST to the server, is being considered as a potential "fix" (that is, what if the page contents are not in the cache or the cache is turned off?). This really alarms me. POSTs, in some applications can be associated with database transactions or content that is changing on the server. There is no guarantee that two identical posts will return the same results. I really would like to see what the webserver sent me, without modification and without making another trip to the webserver, regardless of the state of my cache settings when I view source.
Comment 63•23 years ago
|
||
This cry comes out from many developers. The problem is, for non-developers, not hogging up all the memory is most likely more important than having a pristine copy of everything in the browser's history. So here are the two things that I think need to be done: 1. Make a pref like "Keep source to all history pages" (and maybe a separate one "Keep all images in history"). When this is turned on, have History hold hard references to all pages, frames, and possibly images in the cache. 2. Make it so that pages with hard references can be moved to disk so that at least RAM is not completely consumed when this happens.
Comment 64•23 years ago
|
||
John, IMHO we should never re-fetch the (currently shown) page from the web again if the user does "view source", save or print. Also the "normal" user would suffer from re-POSTing if the page is a buying confirmation to some shopping trip on the web - and he might want to save or print this page. A developer (I think the "standard" user won't ever need "view source") would like to view the code a different developer used to show him the perfect design of this confirmation page. If we do a POST again here, anyone who clicks view source, save or print will risk buying a second item of something he only wants once. As we have the fuctionality lying around, we should simply use it, I think. We don't need to do that for every page in history - just for the one currently viewed. A second case where we would need this is when a second POST might show completely different code (e.g. you're deleting a guestbook entry - the second POST will tell you the entry doesn't exist while the first told you that the delete was successful) - you'd never see the source you want to see in those cases!
Comment 65•23 years ago
|
||
Oh yes, I totally agree. In all circumstances the current page should hold a hard reference to the cached page. I was under the impression that the previous poster was talking about all POSTs for all time, but now, re-reading it, I am not so sure. Anyway, even if we start holding hard references to the current page, IMHO we still need to be able to move these pages and images to disk without invalidating the hard reference.
Comment 66•23 years ago
|
||
back to gordon. all chak did was change view-source from being a "mode" to a "protocol handler".
Assignee: chak → gordon
Comment 67•23 years ago
|
||
So why should I get this bug? Gagan, can you find the owner for view-source?
Assignee: gordon → gagan
Comment 68•23 years ago
|
||
law@netscape.com is the owner for view source (or someone in xpapps). Can one of you necko folks say what special cache flags are required to get the correct source?
Comment 69•23 years ago
|
||
in that case ->law and law: check with darin on the cache flags to use
Assignee: gagan → law
Comment 70•23 years ago
|
||
*** Bug 80989 has been marked as a duplicate of this bug. ***
Comment 71•23 years ago
|
||
*** Bug 81913 has been marked as a duplicate of this bug. ***
Comment 72•23 years ago
|
||
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)
Comment 73•23 years ago
|
||
*** Bug 81403 has been marked as a duplicate of this bug. ***
Comment 74•23 years ago
|
||
nav triage team: Not a beta stopper, marking nsbeta1-. The helpwanted keyword is still there. ;-)
Keywords: nsbeta1-
Comment 75•23 years ago
|
||
Mozilla 0.9 chances a POST to a GET, when the source view menu item is seleced on a page received via POST. This is awfull, because it truncates the POST paramaters from the request an therefor may result in a totally different output sent by the server. If Mozilla doesn't remeber the correct request including the POST parameters, it should not display any source but a warning indicating, that Mozilla forgot the request.
Comment 76•23 years ago
|
||
*** Bug 82489 has been marked as a duplicate of this bug. ***
Comment 77•23 years ago
|
||
Clearing nsbeta- to trigger re-evaluation. This bug is ugly. It is even more than dataloss because it can trigger multiple transactions in a db (is there a keyword for that? 'datagain'? see e.g., the scenario described in bug 81913, and other duplicates). See also how it has just baffled a number of people in bug 81531.
Comment 78•23 years ago
|
||
*** Bug 81531 has been marked as a duplicate of this bug. ***
Comment 79•23 years ago
|
||
*** Bug 81531 has been marked as a duplicate of this bug. ***
Comment 80•23 years ago
|
||
Copying correctness and highrisk keywords from bug 40867 - they are equally applicable here.
Keywords: correctness,
highrisk
Comment 81•23 years ago
|
||
*** Bug 83122 has been marked as a duplicate of this bug. ***
Comment 82•23 years ago
|
||
*** Bug 83221 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
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
Comment 83•23 years ago
|
||
law is not going to be able to look at this for at least 2 milestones, his plate is full for mozilla0.9.2 and he'll be on vacation after that for a few weeks. if this is badly wanted, someone is going to have to take it. thanks!
Comment 84•23 years ago
|
||
*** Bug 84684 has been marked as a duplicate of this bug. ***
Comment 85•23 years ago
|
||
*** Bug 85398 has been marked as a duplicate of this bug. ***
Comment 86•23 years ago
|
||
If anyone would like to see a test case... Go to http://ntiaotiant2.ntia.doc.gov/test/mozillatest.html Submit the form then do view source on the results page. An error message from the server will appear in the source, not the source for the page you are viewing.
Comment 87•23 years ago
|
||
*** Bug 74834 has been marked as a duplicate of this bug. ***
Comment 88•23 years ago
|
||
Test case provided by cweiss@iname.com
Comment 89•23 years ago
|
||
There is a patch from vidur on the root bug 40867. Anyone wants to test to see if this bug is finally about to be gone?
Comment 90•23 years ago
|
||
rbs: vidur's patch covers "save as" only. What needs to happen is that view source needs to use a setup similar to that one (also passing a cache key and all that). I'll try to look into that sometime this weekend...
Comment 91•23 years ago
|
||
While Vidur's patch addresses the simple test case I had posted on that bug it does not address the one on this bug. Actually it doesn't even try, it's focused soley on the save as case. This test case is a much better one than the one I posted. save as: re-requests! (number incremented) view source: fails completely (server error) send: fails completely (server error) print: success :)
Comment 92•23 years ago
|
||
I have code in my tree that makes view source pass the test at http://ntiaotiant2.ntia.doc.gov/test/mozillatest.html just fine (modulo another cache bug, actually, but that bug causes us to get a too-old version from cache at times, which is not nearly as bad as what we do now). The POST data is remembered and the number of requests is not incremented. I'm not attaching a patch yet because I'm waiting on feedback regarding some interface changes I've had to make and because the code has some issues I'd like to clean up before wasting anyone's time with review...
Comment 93•23 years ago
|
||
*** Bug 90203 has been marked as a duplicate of this bug. ***
Comment 94•23 years ago
|
||
*** Bug 80301 has been marked as a duplicate of this bug. ***
Comment 95•23 years ago
|
||
*** Bug 84393 has been marked as a duplicate of this bug. ***
Comment 96•23 years ago
|
||
*** Bug 91456 has been marked as a duplicate of this bug. ***
Comment 97•23 years ago
|
||
I am a web developer and I run into this bug everyday when I am using mozilla to test my code. I can assure you that when view source is choosen, the code is reexecuted, and quite frankly it is driving me nuts because I can never view the source I am looking for since the page is dynamically generated and when the page is reloaded the page is in a different state.
Comment 98•23 years ago
|
||
I just spend several hours till I discovered that mozilla is having major troubles with view-source. Think we should focus on this not to displease the whole web-developer community.
Comment 99•23 years ago
|
||
*** Bug 95149 has been marked as a duplicate of this bug. ***
Comment 100•23 years ago
|
||
and even worse, a form will be resubmitted and the data will show up twice in email/database/stuff. that's not really what anyone wants. the source of the currently loaded page should be in a special variable so that it can be easily used for operations such as VIEW SOURCE and SAVE PAGE.
Comment 101•23 years ago
|
||
Rather than store source in a variable, storing a hard reference to the entry in the cache is sufficient. But that should mainly be for the current page. Do normal users really want the source of the 150 pages they've visited today stuck in memory? (Though maybe if hard references to the cache allowed the cache to put stuff to disk and retrieve on use, it would be a different story.)
Comment 102•23 years ago
|
||
there are two ways to solve this problem (both of which are supported by necko) 1) use a hard reference to the cache entry (called a cache token) 2) use a soft reference to the cache entry (called a cache key) with either of these methods you can identify a cache entry a pull it out of the cache (disk or mem) without incurring a network hit. see nsICachingChannel for details.
Comment 103•23 years ago
|
||
*** Bug 99449 has been marked as a duplicate of this bug. ***
Comment 104•23 years ago
|
||
*** Bug 99971 has been marked as a duplicate of this bug. ***
*** Bug 100529 has been marked as a duplicate of this bug. ***
Comment 106•23 years ago
|
||
*** Bug 100728 has been marked as a duplicate of this bug. ***
Comment 107•23 years ago
|
||
I know this has been said before, but: If developers of dynamic content can't "view source", MOZILLA WILL NOT BE SUPPORTED BY DEVELOPERS. It is not acceptable that when I have problem on a page that I'm developing and go to view source, I CAN"T VIEW IT because VIEW SOURCE makes ANOTHER request to the server and returns something other than what I need to see. How long has this bug been sitting out there? ALMOST ONE YEAR. That's one full year of developers throwing up their hands in frustration, saying, "we can't support Mozilla or Netscape 6 because we can't debug our pages on it". You are slitting your own throats here, and it isn't Microsoft's fault that you are losing market share (for once). Fix it. Fix it now. I want to support Mozilla.
Comment 108•23 years ago
|
||
Here here! I can't believe this one has remained a problem for so long. I'm a web developer, and this is a constant frustration to me and my co-workers. Please make it a high priority... I'd hate to see it slide any longer.
Comment 109•23 years ago
|
||
Well, I don't know what's got everyone all twitchy about this, but I agree with the last two commenters. I started and stopped using Mozilla for debugging and browsing in general back in May. Even Netscape 4.78 is no good, it seems to hide my html comments. I went back and am sticking to 4.77. If I weren't a Linux developer, I'd switch to IE now.
Comment 110•23 years ago
|
||
Actually, if you follow the trail back, I think it's been hanging around for significantly longer than a year - it's just that every time it looks like it's going to be fixed, it gets bumped back. I've resorted to using emacs, w3m, lynx or wget to debug pages, and I think I'll look at Opera and/or Galeon too: It took far too long for this to even be acknowledged as something that needed fixing. And since people seem to be talking about using the cache [unless I've misinterpreted] I'd just like to repeat something that seems to have been overlooked (again): What about pages that are displayed, but not in the cache?
Comment 111•23 years ago
|
||
<QA_Ignore Rant=on> I'm sorry that this bug makes it impossible for you to develop with mozilla. Anyone who is reading this HATES this bug. Bitching about it will only make people resent you. You want it fixed NOW? There are a couple of things you can do to help. 1. If you're a developer yourself, look into the problem and *try* to fix it. (I know it's a hard problem. If it were easy, something as high profile as this wouldn't be a problem anymore, would it?) 2. Add your vote to the 67 already here. (Not to mention the 68 CC's if I can count correctly.) 3. Advocate fixing this bug somewhere more effective, like to any developers you know personally, or on the newsgroups. 4. Really put your money where your mouth is. Find someone who can code and pay them to fix this bug for you. What does another message of 'This is a really bad bug that I can't use Mozilla with, fix it NOW!!!!' really do? Well, it adds another comment to bugzilla that anyone interested in actually helping fix the bug needs to wade through first. Thus they have /less/ time to do what you really wanted them to do. Remember, there are a number of bugs where such comments have gotten so bad that they were closed and re-reported just so that no-one had to wade through the muck anymore. To reiterate: if you want to support having a bug fixed, but don't have the time/skills to work on it yourself, and don't have any information that would directly help someone working on the bug, vote for it or put your name on the CC list. There is little else you can directly do to help. Don't waste the time of those actually trying to get work done. 135 people don't need to get email just because you think this is a bad bug. If they didn't already think that, they wouldn't be following this bug. You're preaching to the quire. </QA_Ignore>
Comment 112•23 years ago
|
||
> What about pages that are displayed, but not in the cache?
Handle them just like a reload. Re-request if there was no post data, prompt
before re-requesting if there was post data.
Comment 113•23 years ago
|
||
As this bug does have 67 votes for it, I'm sure the mozilla developers are well aware of it. I'm a linux web developer and I for one, use mozilla as my primary browser. Every once in awhile I bust out netscape 4.77 to see if I have any broken tables or what not. While it's annoying that I cannot use view source on form posts but I'm just smart about programming and I've been able to make do without view source. I'm confident that this bug will get fixed in due time, it is targeted for moz 1.0. I've just tested it out and here are some tests I did: (0.9.4) 1) normal get, no post data, seems to show the correct page, no addition GET is issued 2) form submit via post to itself, the first page is shown, not the most recent, no addional GET is issued 3) form submit via post to another page, the correct view source is shown, no addional GET is issued So from my 10 minutes of testing here, it looks like mozilla can pull the page from the cache, but it can get confused about which copy of the page to pull from the cache, so a page that you hit twice, but returns different results may show incorrect view source. In none of my test cases did mozilla make another fetch from the server as all the page were in the cache. Someone please correct me if I tested wrong. Give the mozilla developers a break a lot of them work hard with little to no pay. And they have a LOT bugs to deal with. This one's *almost* there.
Comment 114•23 years ago
|
||
Hearing of opera in this 'Thread': Opera has the nice feature to provide the choice of which program to use for viewing. Sorry, no Fix, no patch, just another feature-request...
Comment 115•23 years ago
|
||
> > What about pages that are displayed, but not in the cache? > Handle them just like a reload. Re-request if there was no post data, prompt > before re-requesting if there was post data. AIIK bad idea. if you have a Serverside Application proccessing the post data in dependence of the last request (and its not stateless) you might only get an 'well, my database doesn't love you **** off' error. What about a 'Memory waste' mode for developers copying the data to another buffer vor the view-source? Or even store it to the Disk? this would allso ease the use of an external viewer/editor.
Comment 116•23 years ago
|
||
> What about pages that are displayed, but not in the cache? Developers _NEED_ to see source of actually viewed page. So source code must be stored in memory without using cache system. Maybe this could be feature for developers and they have to enable it in preferences. But developers really NEED this. You CANNOT use for this type of pages any cache system because some cache-directives in HTTP1.1 restrict caching (RFC2068, 14.9.1). > Handle them just like a reload. Re-request if there was no post data, prompt > before re-requesting if there was post data. This is right reverse, what developers need. It's correct for programmer's eye and it is correct according to HTTP standard, but developers need something else.
Comment 117•23 years ago
|
||
Not to mention...as I stated way way back when. The generated page depends on much more than GET or even POST information. The state of Cookies, or even something such as time which mozilla shouldn't track can effect the output of a page. A page that is "POSTED" to could change depending on whether it was after work hours for instance. There are to many examples of this to list, which is why it is so crucial that the original source is displayed, to name a few, time, screen resolution in a user's display (could change while viewing a page which would change (or would it?) the javascript object storing this information), IP/Domain Name (in the case of a renewed DHCP lease), etc. Or something could change on the server side (although in most cases these would be poor designs on the server side). Bottom line, the original source must be used, this is not just a matter of GET/POST/re-POST...... I have been watching this bug for a while as well as one of the dependents, there was a lot of effort put forth on it, and then we lost someone, etc. Has the bug been "re-assigned" to someone that can actually work on it, or is it still waiting in the wings for someone familar enough with the source?
Comment 118•23 years ago
|
||
> Opera has the nice feature to provide the choice of which program to use for > viewing. > Sorry, no Fix, no patch, just another feature-request... This is known as bug 8589 > What about pages that are displayed, but not in the cache? As far as I understand the discussion in bug 40867, the idea is to make sure that this never happens - while you have a page opened is a window, the window would hold a cache reference that would prevent the page from being removed from the cache. > You CANNOT use for this type of pages any cache system because some > cache-directives in HTTP1.1 restrict caching (RFC2068, 14.9.1). I believe this is not true. You can cache whatever you want, as long as you do not try to serve the cached page again. Another way to lok at it is to say that the cache is simultaneously a "view source" cache and a "web cache". If you have a document, that is not supposed to be "web-cached", you still put it into the cache for the "view source" purposes and than, but do not use it for serving future web requests...
Comment 119•23 years ago
|
||
Question. Is it necessary to have the View Source capability for any other page but the one currently being viewed? I don't think it is. So can't we just have a memory buffer attached to each browser window which stores the RAW html for the currently displayed webpage (or webpages in the case of frames)? This would be COMPLETELY independant of the cache system. Sure it would duplicate a little data, but who cares. It would never store this data (like the cache) because it would only ever have the currently displayed page in it. This data could then be used for view-source and printing purposes.
Comment 120•23 years ago
|
||
> Is it necessary to have the View Source capability for any other page
> but the one currently being viewed?
Hitting back and then viewing source is not uncommon....
Comment 121•23 years ago
|
||
The more robust solution that would allow hitting the back button and then viewing source would be nice BUT I don't think it's absolutely necessary. stephena@hiwaay.net's proposition sounds simple and could probably be implemented much more easily, no? And this would go 90% of the way towards satisfying web developers' gripes.
Comment 122•23 years ago
|
||
> I believe this is not true. You can cache whatever you want, as long as you do
> not try to serve the cached page again. Another way to lok at it is to say that
> the cache is simultaneously a "view source" cache and a "web cache". If you have
> a document, that is not supposed to be "web-cached", you still put it into the
> cache for the "view source" purposes and than, but do not use it for serving
> future web requests...
Yes, I could fully agree if we divide problem for 'web cache' and 'view-source
cache'. 'Web cache' is defined by HTTP 1.1 and Mozilla HAVE TO RESPECT this RFC.
So, 'view-source cache' is IMHO only one solution of our problem. If you agree,
is there question, that 'view-source cache' will be enabled for all users or
will be enabled only on user wish. I think, that second case is correct.
Comment 123•23 years ago
|
||
vivek: all content (except that marked with a 'Cache-control: no-store' header) is stored in the cache. IE seems to generate HTML for you when the requested page doesn't live in its cache, and IMO so should we. this is necessary to support File->SaveAs as well.
Comment 124•23 years ago
|
||
Darin: Ok, but if we are generating or refetching in any way, then we are not doing a genuine 'view-source', and the user should be warned and given the option to abort. [As with re-posts on back/forward]. 'view-source' has to mean 'Show me the _exact_ thing you rendered into this page, without triggering any side effects' or it hurts more than it helps.
Comment 125•23 years ago
|
||
Answering Stephen Anderson 2001-09-20 10:58: > So can't we just have > a memory buffer attached to each browser window which stores the RAW html for > the currently displayed webpage (or webpages in the case of frames)? See the complete list of bugs that are dependent on bug 40867 - we want not only to be able to do "view source", but also "save as" and "send page". The "send page" requires us to keep not only HTML, but also images and other data. Also, if you are viewing a page with frames, then you have to keep lots of HTML pages... > This data could then > be used for view-source and printing purposes. As I understand, the printing problem is easier and is separate - we do not need the original source for printing, and the data that is kept around for displaying the page is sufficient to also print it. Answering: Adam Hauner 2001-09-20 11:32 > Yes, I could fully agree if we divide problem for 'web cache' and 'view-source > cache'. Note that this division only has to be "logical", not "physical". In fact, there is nothing wrong if both share the same code, the same mechanisms and the same storage area, all called "Mozilla cache" - as long as entries in that cache are only used for appropriate purposes. As far as I understand, the current proposition is exacly that - to extrend Mozilla caching mechanism so that it can be used for both "web caching" and "source caching" purposes. Answering Darin Fisher 2001-09-20 11:41: > all content (except that marked with a 'Cache-control: no-store' header) > is stored in the cache. IMHO, it's reasonable to have an implementation that would have problems showing the source "Cache-control: no-store" documents. After all, if you are a web developer, you can just avoid using that header while the page is being developed...
Comment 126•23 years ago
|
||
> Yes, I could fully agree if we divide problem for
> 'web cache' and 'view-source
> cache'. 'Web cache' is defined by HTTP 1.1 and
> Mozilla HAVE TO RESPECT this RFC.
> So, 'view-source cache' is IMHO only one solution of
> our problem. If you agree,
> is there question, that 'view-source cache' will be
> enabled for all users or
> will be enabled only on user wish. I think, that
> second case is correct.
I would vote for the former, "enabled for all users" since this is the
behavior that most users coming from Netscape 3/4.x and IE would expect, AFAIK.
Is there any instance that "view page source" should, reasonably, not view the
current page but rather fetch a new page from the server and show its source?
Of course, I'd still cheer for "enabled by choice" if that's the only way this
will get in.
BTW, my apologies for my previous "Fix it. Fix it now" rant. I was out of
line. I can see that there are several people working diligently on this, and
that they've been plugging for some time. Keep it up.
Comment 127•23 years ago
|
||
The currently viewed page can have a hard reference to it. That way, any page that is viewed *will* be in the cache. This solves the "viewed page" problem. The bigger problem is when the page has been changed by JavaScript--how do you show that source, and which one do you show--but I think the original source is good enough for now.
Comment 128•23 years ago
|
||
How does Netscape 4.7 handle view source? Could the same be done here?
Comment 129•23 years ago
|
||
ayn2@cornell.edu: > After all, if you are a web developer, you can just avoid using > that header while the page is being developed... It's not true and not relevant. Developers need view source everytime, not depending on headers served by web-server (very often servers are configured by other person). --- So, Bill Law, what you think about discussion on this topic? (BTW this bug is 7th the most wanted bug in Bugzilla).
Comment 130•23 years ago
|
||
To solve the problem completely and fully: Just make hard references allow the data to go off into the disk--just not to be deleted. This would allow us to save memory but still keep every single bit of session history around in case we need it. Just have every single history item keep its very own hard reference. You could have a pref that says whether or not to do this for non-currently-viewed pages (for people with the pref off, it would simply use the weak ref, meaning the page could be deleted). But I don't expect this as a first-pass solution. Just being *able* to use the cache keys seems to be a big enough problem.
Comment 131•23 years ago
|
||
IMHO, we only need a mechanism for the currently viewed content. If someone does back + view source, that's no problem, we already have mechanisms for back/forward, they will apply, and then we again have viewed content we can show, right? just my 2c
Comment 132•23 years ago
|
||
*** Bug 100939 has been marked as a duplicate of this bug. ***
Comment 133•23 years ago
|
||
*** Bug 102499 has been marked as a duplicate of this bug. ***
Comment 134•23 years ago
|
||
*** Bug 104607 has been marked as a duplicate of this bug. ***
Comment 135•23 years ago
|
||
*** Bug 105554 has been marked as a duplicate of this bug. ***
Comment 136•23 years ago
|
||
*** Bug 105683 has been marked as a duplicate of this bug. ***
Comment 137•23 years ago
|
||
*** Bug 106230 has been marked as a duplicate of this bug. ***
Comment 138•23 years ago
|
||
*** Bug 107948 has been marked as a duplicate of this bug. ***
Comment 139•23 years ago
|
||
*** Bug 64100 has been marked as a duplicate of this bug. ***
Comment 140•23 years ago
|
||
Edward Castagna wrote: After I mentioned on the bug 64100 stream that the save as behaves on Netscape Browser 6.1, I got a response back... Response: ==== I'm using the latest builds from Mozilla for a while now, and the earliest build I have on my system here is one from October 10, and with that version I still get the prompt. The Netscape 6.1 build is based on the Mozilla 0.9.2.1 milestone source code. I don't know if Netscape modifies the code a lot (don't think so), but it is very well possible that some bugfixes has changed the behavioru of the prompt box. I'd recommend you add your findings to the Bugzilla system, so programmers working on the source code might track where the change occured... Kind regards, Kris Ven
Comment 141•23 years ago
|
||
*** Bug 110489 has been marked as a duplicate of this bug. ***
Comment 142•23 years ago
|
||
*** Bug 110717 has been marked as a duplicate of this bug. ***
Comment 143•23 years ago
|
||
*** Bug 110827 has been marked as a duplicate of this bug. ***
Comment 145•23 years ago
|
||
*** Bug 110959 has been marked as a duplicate of this bug. ***
Comment 146•23 years ago
|
||
*** Bug 110864 has been marked as a duplicate of this bug. ***
Comment 147•23 years ago
|
||
*** Bug 111466 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Blocks: advocacybugs
Comment 148•23 years ago
|
||
*** Bug 113304 has been marked as a duplicate of this bug. ***
Comment 149•23 years ago
|
||
Is there a big problem to keep source of the page in memory ? Memory is cheap these days, and it's user's problem if he/she opens 100 windows or more...
Comment 150•23 years ago
|
||
*** Bug 115059 has been marked as a duplicate of this bug. ***
Comment 151•23 years ago
|
||
*** Bug 116070 has been marked as a duplicate of this bug. ***
Comment 152•23 years ago
|
||
Ok, the problem is worse than just the source code being cached. Even the contents of textareas do not change. for a simple example, make a form with a textarea, submitted through post. let your cgi program change the text in the textarea. The resultant page will still have the old text. If instead, you use Content-type: text/plain instead of text/html, you find that the CGI has provided the correct output.
Comment 153•23 years ago
|
||
Source should be attached to the window, not to the specific URL(that URL could produce different contents on each request). If window contents are reloaded, only then source changes. Is it a problem to have in-memory copy of window contents (as it was sent from the server) ?
Comment 154•23 years ago
|
||
In comment #152, Philip Tellis suggest that there is also incorrect handling of form data. I'd like to know if the problem he reports is related to the interaction of the show-source part of the browser and the form manager which sometimes remembers more values than is good (imho).
Comment 155•23 years ago
|
||
more use tells me that it is not just textareas, but any form element. Shows the cached values, or what was entered by the user, rather than what the cgi returns.
Comment 156•23 years ago
|
||
*** Bug 117197 has been marked as a duplicate of this bug. ***
Comment 157•23 years ago
|
||
The form caching bug you are refering to is probably this one http://bugzilla.mozilla.org/show_bug.cgi?id=46845 Unfortunately Mozilla feels the current behavior is correct, please vote for it...it's been ignored for such a huge bug imo. At least this bug has a target milestone.
Comment 158•23 years ago
|
||
About view-source on history pages: Although it's useful to have history pages render quickly, I don't think it's reasonable to keep the original source around for them too. As a developer, if I'm going to want to see the source, I only expect the browser to be able to pull it without a server fetch if I'm doing it on a current page, not a history page. So per-window "latest-page-source" might be the answer here. Anyone else think this way?
Comment 159•23 years ago
|
||
Taral: No, absolutely not. If we can view a page w/o refetching it, then view source _must_ be able to display the source w/o refetching/triggering side effects.
Comment 160•23 years ago
|
||
I disagree. If necessary, a warning can be displayed that the original source is no longer available, with options of "reconstructed source" and "fetch from server". I don't think it's unreasonable to tell developers that if they want the source, it's "now or never".
Comment 161•23 years ago
|
||
Taral: No, absolutely not. If we can view a page w/o refetching it, then view source _must_ be able to display the source w/o refetching/triggering side effects. In other words, I second vivek's point - we can't rely on reconstructed or refetched source to highlight a server-side problem. -- Ross
Comment 162•23 years ago
|
||
<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. ***
Comment 164•23 years ago
|
||
*** Bug 117634 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 165•23 years ago
|
||
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)
Comment 166•23 years ago
|
||
*** Bug 118536 has been marked as a duplicate of this bug. ***
*** Bug 118562 has been marked as a duplicate of this bug. ***
Comment 168•23 years ago
|
||
*** Bug 119008 has been marked as a duplicate of this bug. ***
Comment 169•23 years ago
|
||
*** Bug 119802 has been marked as a duplicate of this bug. ***
Comment 170•23 years ago
|
||
*** Bug 120804 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 171•23 years ago
|
||
*** This bug has been marked as a duplicate of 40867 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 173•23 years ago
|
||
Why is this suddenly a dupe of bug 40867 now, when way back in comment 1 and comment 2, over a year ago, it was remarked that we shouldn't be so optimistic as to close this one as a dupe? What has changed recently? At any rate, I don't really care which bug is considered a dupe of which, but I would like to see it fixed... the lack of a reliable and consistent "View Source" is one of the biggest flaws in the current Mozilla.
Comment 174•23 years ago
|
||
Why has it taken so long to identify this as a dupe? Marking this bug as a duplicate messes up two things: 1. Votes, of which this bug has 162. 2. Most frequently reported bugs. This bug was at the top of the list just yesterday, with about 76 dupes, as i remember. Now that this bug has been duped, the bug does not appear in the list at all: <http://bugzilla.mozilla.org/duplicates.cgi> These two things aren't important if things actually get moving on bug 40867, but that doesn't appear to be really happening. The last patch submitted for 40867 was back in July.
Comment 175•23 years ago
|
||
Can someone please explain why this should be a dupe and not a dependency of 40867? If a fix should knock them both out together, great, but the case of view source will still require seperate verification after 40867 is fixed. Closing out a bug with *the* most votes with absolutely no comment, and verifying it minutes later with absolutely no comment, isn't the best PR move I've seen. This has screwed up dupes, votes, and the dependency tree quite badly.
Comment 176•23 years ago
|
||
> Closing out a bug with *the* most votes with absolutely no comment, and
> verifying it minutes later with absolutely no comment
I verified because:
- I always thought that they are both the same bug (see my initial comments),
but the developer wanted separated bugs, because the issues *might* be
different, so he got his own bug. (His priviledge as developer.)
- The bug filer, assignee and dupper are identical. Again, he knows best what
the facts are. If he found out that the bugs are in fact identical, dupping them
is the logical step
- I wasn't aware how *many* votes, ccs and dups this bug really has, until I saw
the "email sent to" confirmation. (I counted roughly 300 emails sent.)
Now being aware of it, I think, it might make sense to keep this bug open, just
so we have correct vote/dup statistics. law, OK? If so, please reopen.
Off to spamming 300 people again... :-(
Comment 177•23 years ago
|
||
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 → ---
Comment 178•23 years ago
|
||
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.
Reporter | ||
Comment 179•23 years ago
|
||
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 → ---
Comment 180•23 years ago
|
||
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
Comment 181•23 years ago
|
||
*** Bug 121436 has been marked as a duplicate of this bug. ***
Comment 182•23 years ago
|
||
Peachy. Nearly 3 years of discussion (bug 6119) and yet again, this bug gets bumped back. You could have just marked it as WONTFIX to start with.
Comment 183•23 years ago
|
||
i'm only an outsider, but futuring this bug seems a little crazy to me. this bug is both _the_ most voted for (164 votes), and most duplicated (75 dups) and it's mentioned in the release notes. it's pretty clear that it's one of the biggest outstanding issues for many users, and you're futuring it? maybe it's not your responsibility and maybe it wasn't the responsibility of the person who just dumped this bug on you either, but surely someone should take responsibility for it? please?
Comment 184•23 years ago
|
||
Referring to comment #183, suggest you see bug 40867 http://bugzilla.mozilla.org/show_bug.cgi?id=40867 It seems to be the same bug, and something's happening on that. Brian [just another outsider, upset at the apathy about this bug too]
Comment 185•23 years ago
|
||
There are currently six bugs that are blocked by bug 40867, the reuse/reload without refetch bug. They range in Target Milestone from 0.9.9 to 1.2 to Future. As one of the dependents of bug 40867, this bug is, of course, currently set to future. The following two bugs are dependent on bug 40867 and set to 0.9.9: bug 17889, Changing character set reloads the page from web; and, bug 84106, Not correctly retrieving post data when saving a page or frame generated from a form POST. This bug is as important as those two. This bug affects view source. It only affects a subset of users, since most don't know or care about view source. That subset, however, includes HTML developers. I'm not an HTML developer myself, but it's important to keep the HTML development community happy. I support setting the target milestone to 0.9.9 or 1.0. As for a practical solution, bug 56346 has been fixed, so all pages should be cached, either in memory or on disc. The current HTML document should be cached either in memory or on disc. Can't we query the cache to learn where the document is cached? Then, open that file from cache and display in the view source window?
Comment 186•23 years ago
|
||
> Can't we query the cache to learn where the document is cached? Then, open > that file from cache and display in the view source window? This is what bug 40867 is all about. We _can_ do it. Just not from javascript (yes, we can read data from the cache from javascript, but then we can't do anything with that data. No we can't tell the docshell, which _can_ do something with the data, to read it from cache unless we do it from C++). And the people in charge of the API have some reasons not the expose the low-level APIs that can do this to javascript. Possible fixes to this bug: 1) Wait for something cool to happen in bug 40867 2) Create a C++ service which will be scriptable, take data from view source ("data" means post data, url, cache key, charset, docshell) and load that data in the view source docshell by calling nsIDocShell::loadURI (not scriptable), instead of nsIWebNavigation::loadURI (scriptable) 3) Add a cache key (or history entry) parameter to nsIWebNavigation::loadURI. Then use that directly from viewsource.js #1 is not likely to happen anytime soon because it's being overengineered. #2 is something I could maybe do if I had lots of time, which I don't (I'd need to figure out how to get some C++ thing scriptable and instantiated in JS). This method is also a gross hack. May be worthwhile if we need this bad right now and #3 would need approval from rpotts@netscape.com , who owns that interface. I've mailed him with the suggestion.... He vetoed it once, a few months back but maybe the lack of progress on bug 40867 will help.... someone has the time to do it.
Comment 187•23 years ago
|
||
>2) Create a C++ service which will be scriptable, take data from view source
> ("data" means post data, url, cache key, charset, docshell) and load that
> data in the view source docshell by calling nsIDocShell::loadURI (not
> scriptable), instead of nsIWebNavigation::loadURI (scriptable)
Why not do this via the 'file save as' mecanism which allows me to
give an executable to view the unknown-mime-type or to save it to
disk?
You could modify the mime-type to something like html-view-source
or that...
So one could set his desired editor and even more people would
be happy...
Comment 188•23 years ago
|
||
Thanks to Boris Bzarsky for the explanation. Like the last comment said, instead of an extra layer/service or a potential security hole, we could just call a text editor. In Windows, IE 6 still calls notepad.exe for view source. It's ugly, but it gets the job done. HTML developers don't want a pretty interface as much as they want the original source file.
Comment 189•23 years ago
|
||
How's that work for ^R re-using the same window to show the same source again? I don't want it shelling out ; I think that's nearly the lamest idea, and half of my mind suggests it's a troll. Toss up a kiosk window, enable the hotkeys (ctrl-[xcrwqnsepia]) and show the data sucked from the URL instead of rendering. When did it become complicated with MIME-types again? Why do I need to run about closing a million new editor windows?
Comment 190•23 years ago
|
||
Why can't your throw the cached item into a temp file and open it up in the viewer window?
Comment 191•23 years ago
|
||
> Why can't your throw the cached item into a temp file
The hard part would be telling the docshell that the file should be shown as
source, not just as HTML, but that could be done..... Count this as way #4.
This has approximately the ugly hack coefficient of way #2, especially since I
think it would require adding knowledge of view source to things like the
uriloader which should have no such knowledge.
Comment 192•23 years ago
|
||
> yes, we can read data from the cache from javascript, but then we can't do
> anything with that data.
Why can't you do anything with the data in JavaScript? *If* you have the right
HTML source as string, just push it into a window (as text/plain, or do a simple
TXT->HTML conversion and something like document.write()). You'd have no
pretty-printing, but better correct than pretty.
Comment 193•23 years ago
|
||
I think the problem is that it's not stored in raw form, but in a digested format. I agree the "throw to a temp file" is an ugly hack, but it was only an idea, albeit not a very good one. The URI loader should have no knowlege of source file. Unless you did something like raw:// or source:// in which case you _might_ be able to do something... I think it would be way too much work to go that route, and I'm not sure if it would be appropriate.
Comment 194•23 years ago
|
||
> You'd have no pretty-printing, but better correct than pretty.
If we believed that we wouldn't have syntax highlighting either....
Oh, and doing postData correctly via the scriptable cache interfaces would be a
gross hack... we would need to duplicate nsHttpChannel::GenerateCacheKey in JS
and then hope that the algorithm never changes. A bad idea, in general....
This is why ideally we want the HTTP channel to do all the cache access for us.
Comment 195•23 years ago
|
||
CC'ing Gordon & Radha for ideas how to pull this data out of cache
Updated•23 years ago
|
Comment 196•23 years ago
|
||
It's a shame we can't just use the same functionality as <context menu> | Edit Page In Composer | HTML source tab. I bet the embedded products, like Galeon, don't include Composer.
Comment 197•23 years ago
|
||
Hello, (as could be deemed obvious) this bug is a big obstacle when you develop with Zope because it makes debugging hard or impossible. Example: I just got an error message that read: "... Troubleshooting Suggestions * The URL may be incorrect. * The parameters passed to this resource may be incorrect. * A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. [Powered by Zope] " But when I tried to "view source" of that page, all I (naturally) got was a page containing the frameset statement and a <noframes> section saying "This requires a frame-capable browser". Major bummer :( Best, --Toni++
Comment 198•23 years ago
|
||
People, this bug is not for bitching/complaining, we've got newsgroups for that.
Comment 199•23 years ago
|
||
Re comment 197: If you get a frameset when viewing source, you should try "View Frame Source" (a right-click option when you have the mouse pointer somewhere in the framed content). You might still not find what you're looking for, in the case of dynamically generated frame content, due to this bug, but at least that gives you a chance of finding it, while viewing the frameset source will still just give you the frameset code even after this bug is fixed.
Comment 200•23 years ago
|
||
Responding to comment #188: In the essence of time, it would be nice if there were two options to view source, one to view source as it works now (and you can fix this whenever you feel like it) and one to view the source in an external editor. If the second option is choosen, then it would take the cached source and spawns an external editor, but this source would be the source already retrieved and would not have to repost the form data or retrieve the page again (sort of what Konqueror does). Then you wouldn't have to worry about syntax since the editor can do the syntax highlighting. If you could understand why we are all voting for this bug, it is because we need the actual source now, and then you can take as long as you would like to do it correctly with the javascript mozilla interface. Just a thought.
Comment 201•22 years ago
|
||
*** Bug 123166 has been marked as a duplicate of this bug. ***
Comment 202•22 years ago
|
||
*** Bug 124509 has been marked as a duplicate of this bug. ***
Comment 203•22 years ago
|
||
*** Bug 125095 has been marked as a duplicate of this bug. ***
Comment 204•22 years ago
|
||
Re comment <a href='http://bugzilla.mozilla.org/show_bug.cgi?id=55583#c200'>#200</a> and to all. This is a great idea, and with this the problem could be solved in (before?) mozilla 1.0, and not in future. As we can see, this is a very important bug, problem for many people.
Comment 205•22 years ago
|
||
If comment 200 is feasible, then go for it. I realy don't matter in what format/application the original received source is shown. The internet explorer 5.x too uses the notepad to display the source.
Comment 206•22 years ago
|
||
Actually, I think implementing comment #200 decently in an XP way would take longer than fixing bug 40867 (which Rick is actually working on right now).
Comment 207•22 years ago
|
||
*** Bug 125866 has been marked as a duplicate of this bug. ***
Comment 208•22 years ago
|
||
Yes, this issue is extremely painful with regards to attempting to view the source AFTER a form submission, when the URL is the same. I'm working on a system that deals with lots of PHP files, and many of these files use forms. After submitting a form through the PHP file, the URL will be the same, but the content will be different - the actual result of the form submission. Unfortunately, "View -> Source" on the result only brings up the original form source. Not terribly helpful when debugging.
Comment 209•22 years ago
|
||
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,'&'); s=s.replace(/>/g,'>');s=s.replace(/</g,'<');return s;} x=window.open(); x.document.write('<pre>' + htmlEscape('<html>\n' + document.documentElement.innerHTML + '\n</html>')); x.document.close();
Comment 210•22 years ago
|
||
Sure, that's what the DOM inspector does. Too bad the DOM has nothing to do with the original source, which is what _this_ bug is about.
Comment 211•22 years ago
|
||
God its worked! :) Why it's not implemented into view source? Thx Chris!
Comment 212•22 years ago
|
||
This javascript is helpful, but doesn't work as advertized... it added some </tbody> tags to some generated HTML of mine. I don't even know what /tbody does, and I know it's not in my code.
Comment 213•22 years ago
|
||
*** Bug 126521 has been marked as a duplicate of this bug. ***
Comment 214•22 years ago
|
||
The bookmarklet in comment 209 is called "generated source" and is from http://www.squarefree.com/bookmarklets/webdevel.html. I agree with bz and sam that sometimes the generated source can differ enough from the original source that it's not as useful, especially if you're trying to debugging a site. Also, the bookmarklet doesn't ship with Mozilla, so most users aren't aware of the workaround.
Comment 215•22 years ago
|
||
*** Bug 127644 has been marked as a duplicate of this bug. ***
Comment 216•22 years ago
|
||
*** Bug 128031 has been marked as a duplicate of this bug. ***
Comment 217•22 years ago
|
||
*** Bug 128166 has been marked as a duplicate of this bug. ***
Comment 218•22 years ago
|
||
*** Bug 128298 has been marked as a duplicate of this bug. ***
Comment 219•22 years ago
|
||
*** Bug 128529 has been marked as a duplicate of this bug. ***
Comment 220•22 years ago
|
||
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,'&'); s=s.replace(/>/g,'>');s=s.replace(/</g,'<');s=s.replace(/</g,'<code><'); s=s.replace(/<code><!--/g,'<code class=\"comm\"><!--'); s=s.replace(/>/g,'><\/code><\/code><\/code>'); s=s.replace(/<code><script/g,'<span><code style=\"color:blue !important\"><script'); s=s.replace(/<code><\/script/g,'<\/span><code></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,'&'); 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+='<##><'+t.substring(1,i)+'><#/#><#code class=scp!>' +t.substring(i+1,e)+'<#/#><##></script><#/#>';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!><'+t.substring(1,i+=3)+'<#/#>';} else {i=t.indexOf('>',1)+1;s+='<##><'+t.substring(1,i-1)+'><#/#>';}} s=s.replace(/</g,'<').replace(/>/g,'>').replace(/<#/g,'<'); return s.replace(/#>/g,'code>').replace(/!>/g,'>');} x=window.open('','','scrollbars=yes,status=no,location=no,resizable,focus'); x.document.write('<html><head><style type=\'text/css\'>\n BODY {color:#000;background:#fff}\nCODE {color:#00f}\n .COMM {color:#800}\n.SCP {color:#080}\n</style>\n<title>Source of: ' +location.href+'</title></head><body><pre>' + hesc('<html>\n' +document.documentElement.innerHTML+'\n</html>') + '\n</pre></body></html>'); x.document.close(); (sorry for posting so long a comment, I promise not to do this again)
Comment 221•22 years ago
|
||
*** Bug 128298 has been marked as a duplicate of this bug. ***
Comment 222•22 years ago
|
||
*** Bug 128803 has been marked as a duplicate of this bug. ***
Comment 223•22 years ago
|
||
please stop spamming this bug with scripts to do dom source viewing. bug 60426 tracks that
Comment 224•22 years ago
|
||
*** Bug 131582 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 225•22 years ago
|
||
-> rpotts. my patch to bug #40867 fixes this.
Assignee: adamlock → rpotts
Comment 226•22 years ago
|
||
*** Bug 131996 has been marked as a duplicate of this bug. ***
Comment 227•22 years ago
|
||
*** Bug 132215 has been marked as a duplicate of this bug. ***
Comment 228•22 years ago
|
||
*** Bug 132606 has been marked as a duplicate of this bug. ***
Comment 229•22 years ago
|
||
*** Bug 132663 has been marked as a duplicate of this bug. ***
Comment 230•22 years ago
|
||
*** Bug 132740 has been marked as a duplicate of this bug. ***
Comment 231•22 years ago
|
||
I guess this is the same bug as "Save Frame As..." that will try to fetch the source again too, and fail with POST results, and otherwise be too much suboptimal.
Comment 232•22 years ago
|
||
*** Bug 133636 has been marked as a duplicate of this bug. ***
Comment 233•22 years ago
|
||
*** Bug 134024 has been marked as a duplicate of this bug. ***
Comment 234•22 years ago
|
||
*** Bug 134272 has been marked as a duplicate of this bug. ***
Comment 235•22 years ago
|
||
*** Bug 134661 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 236•22 years ago
|
||
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
Comment 237•22 years ago
|
||
NOTE: if you're building from source, make sure you delete component.reg before running mozilla to test this bug. Otherwise it may appear that view-source doesn't do the expected thing.
Comment 238•22 years ago
|
||
I downloaded the 2002040203 build for windows, deleted component.reg before running, and I still have problems. Should I expect to see fixed behavior in this build? A few simple cases seemed to work... the source is shown from a POST form submission that didn't work before. (But that's a different bug, not this one.) The first, most obvious problem is that the tags displayed in view-source have had their case changed. I use uppercase HTML tags, e.g., <H1>, but the view-source has changed the case to <h1>. This bug tracks that the view-source should show, character-for-character, the exact HTML source emitted by the server so that you can debug problems. This apparently still needs to be fixed, otherwise view-source still can't be trusted, and Mozilla can't be used by people developing web applications.
Comment 239•22 years ago
|
||
What you're referring to is bug 57724.
Comment 240•22 years ago
|
||
Should View Source work on this page? http://bugzilla.mozilla.org/buglist.cgi?bug_id=55583 It doesn't for me using 2002040203 on Win XP - I get a download dialog instead.
Comment 241•22 years ago
|
||
Should View Source work on this page? http://bugzilla.mozilla.org/buglist.cgi?bug_id=55583 It doesn't for me using 2002040203 on Win XP - I get a download dialog instead.
Comment 242•22 years ago
|
||
Martin, what you're seeing is bug 76816
Comment 243•22 years ago
|
||
The bug seems not to be fixed for me ... Got 2002040403, when trying to view some page, which posted data via POST method (typically new guestbook entry), it asks me, whether I want to post data again: - no: nothing shows (possibly ok) - yes: shows not the source, but the page (the same page as in the main browser window), but in view-source window With 20020402xx it didn't work either (it didn't show *any* source in *any* case in fact), where is the problem? running win2k, today's nightly with talkback
Comment 244•22 years ago
|
||
#243 Could you please specify the URL you've been testing?
Comment 245•22 years ago
|
||
Yes of course ... If you don't mind reading a bit Czech, try to look @ http://isil.xhaven.net/_private/etheniel/gbook.php ... Press the blue button, on which is something like `~ novy prispevek ~`. The page should change, and there should be title like `Kniha navstev (\n) Pridani noveho prispevku` (and below some input lines. Try to view source there - I see the page like in the browser window (everytime). Yesterday, I tried it here on bugzilla, when I posted the article, someone else did, and therefore there was a `mid-air collision`, or how is it called. I tried viewing the source, and saw the same bug again ... By the way - why does Mozilla ask me, whether I want to download something after processing a search query from the main page (bugzilla.mozilla.org)? The view-source window appears, and then `Downloading buglist.cgi - You have chosen ...... of type multipart/x-mixed-replace;x-view-type=view-source from http://bugzilla.mozilla.org/?? build 2002040403
Comment 246•22 years ago
|
||
Robert, I tried that page and what I see in view-source is what I expect to see. As for the other problem, it was mentioned right before your first comment. It's bug 76816
Comment 247•22 years ago
|
||
Robert, Which version (including platform: Windows? Linux? Mac?) do you see this bug in for the xhaven page? I'm using Linux trunk build 2002-04-04-10 and i when i do view source i actually see the source, not the page as rendered in the browser window.
Comment 248•22 years ago
|
||
The bug viewed in http://isil.xhaven.net/_private/etheniel/gbook.php
Comment 249•22 years ago
|
||
Well, I downloaded today's nightly (2002-04-05-03) and I regret to say, that it is pretty the same. My configuration: Win2k czech 2002-04-05-03 Couldn't the problem be in my Czech system? Can anyone prove that? You can see exactly what do I see in the attachment ...
Comment 250•22 years ago
|
||
Robert, this probably depends on your cache settings. With this bug fixed view-source now reads from the cache. The document seems to immediately expire from your cache (is it sent as no-store or something?). Please file a separate bug on the screwup that happens when you say to resend the data and post the bug number here.
Comment 251•22 years ago
|
||
Boris, you were absolutely right. My disk && memory cache was disabled (set to 0 kB) because of some proxy problems some time ago. Reenabling the cache solved the problem. Should this really be called `a bug`? Gonna send you e-mail, don't want to bother 250 people anymore ...
Comment 252•22 years ago
|
||
You should file a bug about the lack of a warning that mozilla is unable to perform the task correctly!
Comment 253•22 years ago
|
||
OK, filed bug #135833, http://bugzilla.mozilla.org/show_bug.cgi?id=135833
*** Bug 137397 has been marked as a duplicate of this bug. ***
Comment 255•22 years ago
|
||
*** Bug 137479 has been marked as a duplicate of this bug. ***
Comment 256•22 years ago
|
||
*** Bug 138534 has been marked as a duplicate of this bug. ***
Comment 257•22 years ago
|
||
*** Bug 139754 has been marked as a duplicate of this bug. ***
Comment 258•22 years ago
|
||
*** Bug 144794 has been marked as a duplicate of this bug. ***
Comment 259•22 years ago
|
||
*** Bug 148072 has been marked as a duplicate of this bug. ***
Comment 260•22 years ago
|
||
*** Bug 137204 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Status: RESOLVED → VERIFIED
Comment 261•22 years ago
|
||
v
Comment 262•22 years ago
|
||
*** Bug 162211 has been marked as a duplicate of this bug. ***
Comment 263•22 years ago
|
||
OK.. now someone gave me that bug-number (I first posted at a "wrong" number - bug 57724) 1.2a, 20020907, MultiZilla/v1.1.22 when using view-source on php-pages, you get a to "standard-values" resettet sourcecode. Post data, that you got from forms (process it and get results (eg sql)), won't be resend with a call for the source of the page. Makes html-troubleshooting a little bit complicated ;-). I think the bug should be reopened
Comment 264•22 years ago
|
||
Frank, are you using multizilla's "view-source in a tab" feature? If so, they're just doing it wrong. Hence the problem.
Comment 265•22 years ago
|
||
The view-source bug in MultiZilla is already fixed. I just forgot to commit my changes in our cvs tree, so Raj (our webmaster) did a commit for me, but he didn't had the latest update of multiviewsOverlay.js. FYI: I'm not at home but visiting my father so that is why I couldn't do a cvs commit (:
Comment 266•22 years ago
|
||
This bug appears to still be occuring for me on Build ID: 2002120108 on Windows XP Home Edition therefore.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 267•22 years ago
|
||
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
Comment 269•21 years ago
|
||
Using Milestone Release 1.4 on Windows 2000, Mozilla does not use the cached source but asks for submitting the POST data again. Want to try yourself? Go to http://democam.mobotixserver.de/cgi-bin/store2rom press the button, wait for the page to return and then do right-click -> View Page Source. Now a popup window will appear telling you that the "page you are trying to view contains POSTDATA that has expired from cache". As a web developer I found this behavior very awkward as you don't get to see the HTML source of the original POST request. You have to submit the request again. That may result in a completely different page as the web pages are created dynamically. Should I file a new bug?
Comment 270•21 years ago
|
||
Huh? Can't reproduce this on 1.4 under linux. And yes, file a new bug if this is reproducable.
Comment 271•21 years ago
|
||
Arthur, I just tried the URL on Linux using Mozilla 1.3 (Gecko/20030312) and the pop up window does *not* appear. Maybe the bug is related to the Windows version only? Here is another URL to check out: - Open http://www.theregister.co.uk - Enter something in the text box and press Go! - View Page Source. That page includes a timestamp that is updated every minute. So at least on Windows I get a different source view every minute. But maybe that problem is already coverd by bug 57724 ?
Comment 272•21 years ago
|
||
I can NOT reproduce this in Mozilla 1.4/Windows 2000. I do NOT get the pop up message and the view source correctly shows source for what is displayed. Make sure your cache settings are fine.
Comment 273•21 years ago
|
||
No troubles with 1.4final on Linux - as far as I remember 1.3 was OK as well ... could be Windows-only problem although I doubt it (since I use Windows with Mozilla sometimes and haven't encountered this bug for some time) ...
Comment 274•21 years ago
|
||
You are right, I just installed Mozilla1.4 on a second W2k computer and it does not display the "POST resend request". So it has to do with my special setup. Mh, my Advanced -> Cache settings are the same as on the other computer: 50 MB Cache size and "when the page is out of date". about:config says that browser.cache.disk.enable is true. The difference is that I am using a proxy on the computer where the popup appears. The HTTP Header from the page that comes from the proxy looks like: HTTP/1.0 200 OK Content-Type: text/html Cache-Control: no-cache X-Cache: MISS from firewall.mobotix.net Proxy-Connection: close Pitty, I can't sniff the HTTP data on the other computer where everything works ok.
Comment 275•21 years ago
|
||
That dialog about POST data is what you get when Mozilla no longer has the original source for the page -- in particular, when that source has expired from cache. There's a bug report somewhere about holding on to the source in some special form outside the cache to prevent this from happening....
Comment 276•21 years ago
|
||
bug 91875 ?
Comment 277•21 years ago
|
||
No. Bug 166786
Comment 278•21 years ago
|
||
Boris, so the proxy (Squid) is adding these HTTP headers which make Mozilla "forget" the pages and thus the source code? I have to try and compare these headers with those on a direct connection.
Comment 279•21 years ago
|
||
I finally figured, it is not the proxy. I did a clean install of Mozilla 1.4 and now it works as it should. No more pop ups asking for resending POSTDATA. See Bug 166786. Sorry for wasting your bandwidth.
Comment 280•16 years ago
|
||
For any page which is visible, "Save As", "Print", "View Source", "Open Frame In New Tab" and similar functions should never, under any circumstance, open a network connection. The viewed pages must be stored raw in RAM or disk cache, any other method is faulty. HTTP headers or meta tags specifying not to cache a page should have no bearing on the user's ability to use the currently viewed page(s). How is this not completely obvious, and how could the developers ever think that doing it any other way could possibly be considered "better"? Only in Gecko browsers can a person on dial-up spend 45 minutes downloading a 4.5MB JPEG file, right-click and select Save As, followed by the browser redownloading the image again! No other browser does such stupid things.
Comment 281•16 years ago
|
||
I have to agree here. We have far too many stupid servers blindly setting Cache-Control or Pragme: no-cache to be dumb about following those instructions. Items that are expired should not be removed from the cache until they are no longer "referenced" e.g. by windows/tabs. Recommend REOPEN.
Comment 282•16 years ago
|
||
Bug 288462 provides the full summary of all related issues, complete with RFC violations. Should be linked to this one.
Comment 283•16 years ago
|
||
Taral, this bug fixed the no-cache behavior. That was the whole point of this bug. At this point entry expiration for view-source purposes does not depend on anything the _server_ does. It only happens on cache collisions or cache getting full. Of course you could have checked this trivially yourself instead of sending content-less mail to dozens of people....
Comment 284•16 years ago
|
||
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.
Comment 285•3 years ago
|
||
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 !
Comment 286•3 years ago
|
||
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.
Description
•