81–90 of 97 posts
It's a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=307089 Or, it's a memory saving feature. To implement "View source from cache" requires keeping around the raw page HTML, which you might not otherwise need after parsing - except you probably will for all the developer tools to work, so this probably should just be considered bug.
> requires keeping around the raw page HTML Isn't it already in the browser's cache in that state anyway? And if the cache is small, the preservation doesn't even have to be "for all tabs," if the last few pages can be retrieved from the cache nobody would complain that the older ones behave as they behave now -- you typically don't do "I wonder what was the source of the page from yesterday" in this old tab, but eve…
Like disk cache as in Cache-Control? In most cases you wouldn't cache the HTML itself, but in cases where you do then your use case should already work as stated, since for the browser to do otherwise would imply the cache is being intentionally ignored for the view-source request.
Once the DOM is ready, the browser has no need to keep the original source in memory or cache. For how many page views does the user want to view source? One in a thousand? You're asking the browser to waste space storing something that it will only rarely be asked to display.
Earlier quoted context omitted.
If you want to see the page as it's currently being rendered, looking in the developer tools seems more relevant anyway.
If they wanted that, they'd have looked at the developer tools to begin with. Many of you folks are completely missing the point. The world wide web took off in large part because it was incredibly easy to learn HTML, because with every webpage if one wanted to know how it worked one could just look at the source code. How the page is currently being rendered, what state the DOM might be in... These things do not mat…
Earlier quoted context omitted.
Isn't that one of the issues nowadays, that people have the attitude "we have enough memory" and thus don't tend to care about optimizing for memory usage anymore. Your suggested solution, about discarding when memory is needed, solves this problem. But it solves a problem that would be created by needlessly storing a lot more data than needed. So it's a solution to a problem that was not a problem to begin with. But…
> "we have enough memory" Your phone is in disagreement.
If you are saving 57 kB per tab open, that'd be ~5,7 MB with 100 tabs open. But if you have 100 tabs open on a mobile phone (!!), you have a bigger problem, and all those tabs are causing swapping already anyway. In that sense, enabling the feature by default makes sense. And don't forget that some people don't have flat rate internet.
Earlier quoted context omitted.
Yes, but if you have more than enough memory, then that's no problem. So, the browser should load the HTML page into a part of memory that can be discarded by the OS if the OS needs more memory. Actually I think it is strange that no such memory API exists in Unix. EDIT: Anyway, storing it in the browser's file cache would also do the trick, I suppose :)
You are talking about an OS-provided cache for the browser to store it's own cache in? There's little sense in that.
For the same reason, OS X and Android Linux both have systems for OS managed caches, and AFAIK Firefox already uses these: https://bugzilla.mozilla.org/show_bug.cgi?id=748598
The status on mainline Linux is a bit more nebulous (seems Android's ashmem has been upstreamed, but it's not directly usable on GNU/Linux systems?), and other efforts have stranded: https://lwn.net/Articles/602650/
For some more thoughts about memory management on OS level vs. application level, I can recommend this "random outburst" from the designer of the Varnish HTTP cache: https://www.varnish-cache.org/docs/trunk/phk/notes.html
Earlier quoted context omitted.
No, because when you want to view the source you mean to view the source of this very document, not the source you'd get by asking to reload the page, it is often different.
If you want to see the page as it's currently being rendered, looking in the developer tools seems more relevant anyway.
There are edge cases where a bug is intermittent... and is masked by something on the client side, especially possible with browser plugins. In fact, plugins were the cause of 2 of these for me... Where some issue on page load was causing a bug, but then JS was changing the source away from what cased the bug, but a refresh wasn't guaranteed to have the same information (this was a fast changing log-viewer, for one of them) ...
So you end up not being able to capture the init state of the page... but the bug wouldnt show up without JS enabled because the error is in the JS...
Not common case... but it seems like fetching from the server is MORE work for no reason when the data is already there...