really not sure who should own this but I'm sending it over to DOM folks for an initial look.
Saving the DOM and JS Contexts in memory is not the sollution here, and that would be a huge waste of memory. Once the cache is working perfectly the gain from doing something like this is very small since parsing a small file is *really* fast as long as the file comes from the cache, parsing a big file can take a while but saving the DOM for a big fie in memory is out of the question. IMO this adds far more complexity than the gain in doing this is worth, and it's not as if mozillas foot print is too small as it is, so I'm marking this WONTFIX. Jonas, there are other far more elegant sollutions to all of those bugs you mentioned, storing frame stat in the session history being one of them.
I agree that the bugs above is not a satisfactory reason for implementing this feature. However this feature is the only way to get the ability to go back to a dynamic page. Loading from cache will only get you back to the url not to the page as you left it. We are currently going from having just static pages to having compleate applications in your browser, that is why we have DOM and JS. As we all know mozilla is the browser to use if you want to make more powerful pages so marking this a WONTFIX is a step in the wrong direction IMHO. I agree that waiting until the bloat is down is a good idea but please don't mark it a WONTFIX
I would really like to have the ability to go back to pages other than normal static HTML pages. I think this RFE is the only way to get this working so I'm reopening this bug. Feel free to mark it WONTFIX again if you disagree with me or think that "back to dynamic pages" should be filed as another RFE
Sorry, forgot to actually reopen...
Setting target milestone to future to get this off the PDT radar.
Adding perf keyword since implementing this would increase performance on back/forward
Some thoughts I just posted to porkjockeys on this issue.... I'd worked out a design for this with Travis way back, when he was reworking webshell and session history (with radha.) I thought he'd posted it, but I can't find it on mozilla.org anywhere. At the time, we were debating whether it was worth the in-memory bloat to store the DOM, as well as the extra mechanism for saying "I have x bytes to use for such a cache" or "I am willing to store x number of pages in the back direction," and maybe "I am also willing to store y number of pages in the forward direction." We decided we'd need to run some experiements to see how much time DOM creation was taking (once the cache was fully operational), vs. the rest of the cost of bringing up the document (primarily style resolution and frame construction), and then decide if it was worth adding the extra code and complexity and bloat for saving that amount of time. I don't mean to phrase it in negative terms, but I want to be clear that "just caching the DOM" isn't free. Bindu sends around some great timing numbers every week that break down the layout process into content creation, frame construction, etc. Bindu or Marc, can you post a pointer to the latest in case anyone is interested? We discussed going further: what about caching the frame tree as well (and therefore the computation for style resolution.) If the containng window had not changed size, you'd get extremely fast display. Even if it had changed size, you'd get just a resize reflow rather than a full reconstruction. With such a system, you'd get the added benefit that the tear-down cost of the previously-displayed page could be delayed until after the next page is shown, maybe even spun out on a separate thread. Being past the deadline for adding functionality, I think this is pretty academic. But I'd love to see the spec posted (if it can be found), or have someone rework the design with real numbers plugged in so we can make an in/out decision for 6.01.
This would be the best way to implement "History Lists" as defined in RFC 2616 (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 and bug 56346 "Need to cache *all* pages for session history purposes"). RFC 2616 says "a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved", but IMHO it's even better to show what they saw at the time when they left the resource. But it would cost much memory. So, how about saving the DOM on disk instead of memory (could be a pref)? IMHO, performance is not the main benefit of this RFE.
I think the best thing would be to keep a certain number of DOM's in memory and after that revert to using the cached file. (I think this was originally discussed in the NGs but it didn't seem to get in here). This could even be combined with busters idea to keep the frametree in memory. For example you could have the previous page's frametree/DOM/JS in memory, the three preceding pages DOM/JS in memory and the pages further back just have the response cached.
Is there an event that gets fired when we leave the page? If so, a page might expect to never be returned to in the state it left itself, and storing the DOM might break some pages.
Yes, there is the onunload event on the window/document/body that fires for all documents that have such an event when you leave the document/close the window. Saveing the current DOM and JS state is extremely complicated and *will not* work unless content developers are aware of it, and they're not so I wouldn't expect that to ever be done...
In this case, yes, I don't think this can be done in a way which is consistent and 100% correct. The only way I can see that we could get to a state where this could be done is if a page could opt-into this feature, which would mean a change to W3C standards (not sure which one is best).
Read my last comments as applying to dynamic pages. Obviously you still could cache the DOM and stuff for static pages so as to get a speedup, if it was worthwhile.
Regarding breaking existing pages: IE does this and I've never heard anybody flaming them for it. Ok, just because IE does something it dosn't mean it's good or standardscomplient ;) Regarding breaking standards: I'm not sure if the standards say anything about wether it's ok to restore state of a page when going "back". We do restore form-values which could break pages the same way restoring DOM or JS-context can. In fact restoring only parts of the state (only formvalues but not DOM/JS) sounds even more dangerous IMHO
This sounds more like a Networking:cache [rfe], doesn't really sound like DOM 0 except for the IE bit, Maybe DOM Other? Not sure if it is related but see example technique 2 in guideline 2 in the UAAG-TECHS document http://www.w3.org/TR/2001/WD-UAAG10-TECHS-20010622/guidelines.html#gl-content-access
*** Bug 113721 has been marked as a duplicate of this bug. ***
Ok, since my bug got duped against this - How about we give this (keeping the docshells around as a cache) a try? This idea would produce a very user-noticable speedup; click ... Back is one of the most common things done on the web. Think Ebay if nothing else. As best I can tell, firing OnUnloads (when we move it to the cache), and OnLoads (when moving it out of cache) should be sufficient, if combined with logic to decide when not to cache pages (or to throw away the cached page, for example if it's expire time has passed). Some random measurements on a slow Win95 machine (233MMX, 64MB) - forward and back between a ebay search list and a listing (after doing it several times to make sure everything was cached) took circa 15 sec for a recent mozilla build, and circa 7 seconds for IE. I'll do some measurements on faster machines and post after lunch. My belief is that if we cache the docshell we should be able to do it in a a second or two.
How would we get the scripts written in, in the right state, when we return to the page? If we save the textual contents of the scripts and reevaluate from the beginning, we'd have the problem that |document.write| wouldn't put things in the right place. If we instead save all the script objects, we'd be firing onload handlers with all the variables set that should be unset, etc. Or is there a simple way around this? (Would you just reconstruct the way we do now for pages that have scripts?)
expiredate and no-cache headers should IMHO not be respected when going back (or forward). When i click back i expect to get back to the page as I left it, even if it has changed on the server. However when i click on a link it should always respect cache-headers, even if the same URL exist in the "history-list". I think we currently do this when getting unparsed pages from cache.
Randell, how about we concentrate on making our runtime memory footprint even close to acceptable before we even think about keeping a few extra DOM trees in memory for fast back/forward? IMO doing that is time way better spent.
JST: You have a good point that our footprint is too large. However, the difference in apparent speed/usability to the user for footprint reductions (while hard to quantify due to machine differences) is low; the difference in perceived speed for improving Back may be much larger. I have 300+MB on my machine at home; I'm willing (on that machine) to trade some ram for speed. On investigation, the browser I've worked on had these requirements for using cached documents (views in spyglass parlance): Don't use the view cache if: a) the document expired b) if it's a frameset, unless it's a wysiwyg frameset (?) c) if the page has OnLoad, OnUnload, OnBlur, OnFocus, onClick, onMouseMove, onMouseOut, onMouseOver, onReset, onSubmit, onFocus, onSelect (ok, that's probably all of them), or a script (that we understand) When we do the cached load: a) start loads for any missing images b) change window name, scroll position, etc c) no need to fire onloads (since we don't cache if it has them) When adding to the cache: a) no need to fire onunloads (since we don't cache if it has them) b) if it's in the cache already, destroy the old copy (if size > 1) As you might guess, this was done to make JS contexts work correctly (the original spyglass browser didn't have JS, we added it ourselves). On the other hand, I also know that back does seem slow, and in my simple test it was circa twice as slow as IE on a slow machine. On a faster Win98 machine (650 PIII), the difference was harder to measure, but IE was noticably faster - almost instantaneous for back/forward. Total time was <1.5s, much of which was reaction-time delay, and probably 1/2 that time was waiting for the scrollbars to settle (i.e. for non-visible portions to finish laying out). Mozilla was ~3s, and felt much slower. With jprof pages (large with no scripts or images), on the slow machine IE takes about .75s to go back from one jprof to another; Mozilla takes 9.5s. I also tried this on the spyglass-based browser on a fast machine; back and forward take <0.25s. Having this caching done on pages only with no scripts knocks out a lot of pages, but the caching would still help you with a lot of things like HTML docs, etc. BTW, you could make the argument that nothing needs to be re-run (other than restarting anims, etc) on back/forward, and that those just move you around a virtual stack of open pages (much as if the user kept using "Open in new Tab" and closing tabs). This solves some of the issues with going back/forward to dynamic content. (This is to an extent what I think sicking was saying). The counter-argument is that NS 4.x (and IE I assume) fire onload/onunload, though it would be interesting to verify exactly what they do.
This would be a nice speed-up to Mozilla. It could be implemented in an efficient manner. It is too big of a change for 1.0 at this point, though. Nominating for Mozilla 1.1.
As this one blocks bug 33269 the target milestone should be reset.
Here's an idea (might be dumb because I don't know the internals of Mozilla): after loading the document and parsing the source make a copy of DOM tree and JS context before running onLoad. All the document.write's that happen immediatly can be run, though, because they would happen next time too. After going forward throw away normal tree and JS stuff like currently but keep the copies in memory (up to user selected amount, of course). When user presses back proceed to continue with saved DOM tree and JS context. The only thing that needs to be done is launching onLoad and running the page normally - of course DOM tree and JS context should be copied again so that user can use back to return the page again after going forward/following link another time. This all comes to whether or not DOM tree and JS context can be effectively copied in memory - I'm afraid that both would need to be implemented as copy-on-write for this to make any sense.  Some advertisers with document.write()s generating new file name for every page view might be unhappy. Bad luck.
*** Bug 84286 has been marked as a duplicate of this bug. ***
*** Bug 33269 has been marked as a duplicate of this bug. ***
This proposal would eat ridiculous amounts of memory (we're already too fat) which would cause us to take even longer to swap in and out of memory and which would therefore just slow us down. It has huge problems with implementation (i.e. what to do with scripts) and has been repeatedly shot down by the DOM module owner (jst) and what is currently the closest we have to a Layout module owner (dbaron). I suggest we go back to WONTFIX. sicking: You say that IE does this. Could you provide some evidence? Cheers.
I can tell for certain that we did this in MozillaClassic, in the Mariner work, because I touched the code. I wouldn't be surprised at all to discover that IE did the same thing, since it's a great way to make back-forward -- perhaps the most common user actions in a browser, after link-clicking -- go really quickly. (As long as your DOM and other representations aren't enormous, that is.) It certainly made an enormous difference in back/forward speed, and Mariner's back/forward time was faster to begin with. I'm not sure what Mariner did about scripts in this case -- probably just fired onLoad -- but CVS would know.
I'm sure IE keeps data cached in some post-processed form for back/forward. I have a large html file, and I did some tests in IE5. I load the file: 13 seconds. I reload it: 13 seconds. I browse to a blank document, then hit back: 6 seconds. Caching the DOM doesn't sound like a good solution to me, but what if the parser created a flat structure from which the DOM could be quickly constructed? The size will be known, so it can be placed in the cache and obey the limits set in the prefs. Since it will be attached to the original file in the cache, it will be used in all cases where it has been determined that the file hasn't changed, not just back/forward. And I don't see any possible conflicts with scripts and standards. It should behave exactly the same, just faster. To slim things down further, this cache can point to byte offsets in the original file for the start and end of strings, rather than contain those strings itself.
Well, one problem is that you have to spend the time serializing that stuff to disk, when it's likely that, for any randomly-selected page, you're not going to go [<-Back] to it. We could extend the fastload code for this, I suppose. We talked long ago about doing this for scripts, because we've had the serialization code there for ages, but at the time the cache wasn't done, and we had other stuff to do. Sounds like someone should do an HTML fastload patch and post some numbers.
*** Bug 155050 has been marked as a duplicate of this bug. ***
I'm not able to get IE to do this. I no longer remember how i came to the conclusion that IE did this, but i could very well have been wrong.
Who's working on this one?
Nobody is, AFAIK.
*** Bug 167310 has been marked as a duplicate of this bug. ***
*** Bug 169518 has been marked as a duplicate of this bug. ***
Forward and Back Button Behavior in Internet Explorer: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q199805 Opera cache: http://elektrans.opera.com/resources/history-cache.html Performance and the XML DOM: http://msdn.microsoft.com/library/en-us/dnservice/html/service06202001.asp (Dunno if there's anything of interest in these links but it's worth a shot.) For those wanting a speedy back button now, you can always do something silly like setting browser.cache.check_doc_frequency to 2, then mapping your middle mouse button to CTRL-F5 ...
*** Bug 117247 has been marked as a duplicate of this bug. ***
*** Bug 180534 has been marked as a duplicate of this bug. ***
also see mike lee's idea (hack) about a "hidden" tab: http://www.exitspace.net/mike/blog/archives/2002_11_01_mikelee_archive.html#84516896
Perhaps I'm missing something, but wouldn't keeping the entire page in some sort of hidden window/tab someplace so that it could be recalled speedily prevent us from firing onUnload events to those pages? It seems like this approach has exactly the same problems as any other suggestion with respects to script states. I don't think it's going to be safe to do this, unless the page doesn't have an onUnload handler (or any recurring timer events that it depends on?). For those types of pages, it makes the most sense to reload the page from a cache and re-enter it (calling onLoad again, etc.). The URL's in comment #39 describe the best behavior to target, in my opinion. Perhaps what we need instead of caching the DOM/JS context is just to store every page in the cache at retrieval time. Pages that wouldn't ordinarily get cached for any length of time (as expressed through HTTP caching headers) would somehow be flagged as volatile and would be ignored/destroyed (as if expired) for "real" requests (loading it through any other means besides Forward/Back). Even this approach would need to be done carefully, as an external resource might change and be loaded (recached) through a later request, changing the appearance or behavior of the original page when a user clicks Back. Tricky. (FYI, this bug was just posted in a Slashdot comment along with a "call to arms", so I imagine the votes will be going up a bit.)
In parrot, you have the parser output a machine-readable bytecode -- something the interpreter can quickly translate and execute. We could do something similar here: separate the parsing and execution steps with an intermediary bytecode of sorts -- something that both executes and caches efficiently. Apple does window caching in the OS X WindowServer. Hiding and showing windows is done quite effectively without lots and lots memory, and they're working with 32-bit images. The system appears to be working quite efficiently; hiding and showing is smooth and responsive. There's likely a way to store freshly parsed DOM trees without eating lots of resources. What's the current figure, without optimizations or compression, for the current test suite (individual or entire)? (Hello from the Slashdot crowd. Yes, I voted; attention is good.)
how about this? cache the tree of the one or two most recently visited page (the page you will get from hitting back button) in memory, with older pages in disk cache. when you hit the back button, the tree of the previous page will be loaded (fast), after the page has been displayed, move one disk cache to memory. in short: make a stack of tree of pages with the few top most pages in memory, while the tree below is in disk cache, when the top of the stack is popped, move one page tree from disk cache to memory. i am no professional programmer, may be i am entirely wrong, any comment about this?
Please, read the whole discussion before posting. The big problem isn't how the old pages should be stored (cache, hidden tabs or something else) but how to make the scripting work. Namely, onLoad and onUnload actions need to be working as specified. I think the hidden tabs solution sounds like the easiest one and the performance of changing between different tabs is very good already. The solution to scripting problem is that when a new link is followed we work just like normally, but in addition to that we reload the previous document *from cache* in a hidden tab. Or we almost reload it--we must stop just before onLoad takes action. After user presses back we just display the hidden tab, fire the onUnload action in the now-hidden-tab and fire the onLoad event handler. After that, we reload the forward document again in a hidden tab to be ready in case the user decides to press forward button. Again, the reloading should halt just before firing onLoad event. Pros: easy to implement (just create a tab every time we need to add to history, hide some of them and rewire back and forward buttons). Cons: excessive reloading can waste a lot of CPU cycles, pressing back multiple times and then following another link requires removal of multiple hidden tabs, keeping whole page structure ready can take pretty much memory. Could somebody with enough knowledge of XUL create a simple demo. No need to hide tabs or anything, simply make it work so that clicking a link follows a link just like today, but in addition opens a new tab that reloads current page from cache. Back button should be modified to change that "previous page" tab instead. Is there any way to load document up to the position the onLoad event should fire? If this seems to be working, future optimizations could include reusing hidden "history tabs", priorisation of reloading history tabs and loading of foreground tabs, and a more intelligent way to decide when reloading the page is really required instead of simply launching onLoad and onUnload events. One thing to consider is window resize performance if this gets implemented. If I currently load multiple complex pages in tabs and resize the browser window the repaint can take quite some time because all the non-visible background tabs take CPU power to resize too.
Could this option be made optional? I think this is a good idea, but people with slower computers may not.
I think the idea of creating hidden tabs is very interesting. Another idea is to have tab opening by default in foreground with the back page in the back ground. If the user goes back the new tab is hidden, if they go forward the background tabs gradually scroll off into disk cache.
Is there already a bug filed for the slow-resize-with-multiple-tabs thing?
*** Bug 189824 has been marked as a duplicate of this bug. ***
I'm the original reporter of one of the bugs marked as a duplicate of this bug ( http://bugzilla.mozilla.org/show_bug.cgi?id=117247 ). An interesting feature of 117247 is that it got fixed without 38486 being fixed. If anyone else following this has a bug that's a less-than-obvious duplicate, it might be worth retrying it. In fact, I find it's generally worth retrying my open (and closed) bugs every now and then. Surprising things can happen without any explicit change in bug status in bugzilla:-)
Mozilla should keep the DOM around for pages generated entirely with DOM2 in order to prevent dataloss. Currently, going Back to a page generated entirely with DOM2 gives a blank page. (In one of my bookmarklets, I work around this bug by setting target="_blank" on all links.) Once that's fixed, determining whether it's worth doing the same for other pages (perf vs. footprint) might be easy.
*** Bug 223303 has been marked as a duplicate of this bug. ***
This BUG was opened 3.5 YEARS ago.
Jay Davis: stop spamming bugs with useless comments. Or should I write COMMENTS, to ape your shouting YEARS. Unless you're here to help implement, please follow bugzilla etiquette. /be
I cannot believe that "Nobody's working on this" as the bug states at top, it has 111 votes right now, it is a huge performance failing of Mozilla if not the biggest right now, and it is not a blocker. Maybe now that 3 1/2 years have gone by, it should be a blocker. I really doubt that the way things are going, that anything will ever be done with this before Mozilla suite is retired. I will personally put up $1000 to get this fixed. If it is fixed within 1 month, and as long as the person who fixes it doesn't do it for Firebird for at least 6 months because I'm sick of the recent trend of all Firebird new features never making it over to Mozilla. After 1 month, I will offer $600 until 2 months is up. After that, $300. Others here might want to consider adding their own $ reward. Programmers can try to work out together ahead of time how they could split the payoff.
sorry for the spam... slight summary tweak to make this easier to find.
Actually, whatever the specifics turn out to be in a reasonably good solution to reaching 80% or more of Opera's performance back/forward and a distinct lack of reloading the majority of currently reloaded pages will perfectly satisfy me. Mozilla doesn't measure up right now. This has to be fixed or it's going to kill it.
*** Bug 228748 has been marked as a duplicate of this bug. ***
*** Bug 229980 has been marked as a duplicate of this bug. ***
Yes, please fix this. The long wait to go "back" to the previous page is the biggest shortcoming of FF and causing many of us to consider "going back" to Opera.
thank you for volunteering to fix this very complicated bug. in the future i'd suggest you volunteer to fix much easier bugs. this one involves rewriting the entire cache architecture. please inform us as to your expected completion date.
timeless: cut the crap, two wrongs don't make a right, etc. /be
(In reply to comment #64) > timeless: cut the ****, two wrongs don't make a right, etc. > > /be Does anyone think that another bug should be created for Firefox, similar to this, but be considered a enhancement. It would say, "Improve the caching of pages to prevent any unnecessary reloading or rerendering of pages when going backwards and forwards to be as fast as Opera" That keeps it open and might attract more attention from the devs, because this bug is 4 years old, sort of confusing and too specific and probably not going to be fixed this decade. It's also a bug that heaps of people want fixed. 191 votes and many threads over at Mozillazine such as http://forums.mozillazine.org/viewtopic.php?t=171478&highlight= . For people who have tried Opera it is one of the things that most impresses them about it and I think it would improve retention rates with common users, because it's something that every person why tries these browsers notices.
firstname.lastname@example.org: "Core" bug means ff/suite/anything as well.
"Improve the caching of pages to prevent any unnecessary reloading or rerendering of pages when going backwards and forwards to be as fast as Opera" I do think that rewording the bug description would enable far more users to find this page via the search engine. I'm not an advanced techie, and probably never would have made it here except for a kind soul in the newsgroup. If you want more votes for this bug, make it more readily findable. Currently we have "Cache DOM and JS context in memory to provide fast access when clicking back". I think the key is to include common discriptives beside cache, such as slow, paint, navigate/navigation, render(ing), history, compose, etc., which people would tend to use in trying to find a bug listing. I used "historical navigation" to first describe our problem, but that might not be too common. IME, this bug is FF's greatest weakness, by far. I frequently encounter it once a minute or more. As mentioned, it's lack is what sets Opera apart from all the rest, now that other features such as tabs are becoming more common.
it's not an issue of weather users want faster back/forward or not. Of course they do, and so does all mozilla developers. The issue here is whether the cost of the additional memory needed to implement this would be bigger then the speedup gained. The math is hard to do since a lot of these things are hard to measure and they vary from platform to platform, and from webpage to webpage. In the end, "fixing" this bug might slow mozilla down due to the added memory consumption causing disk-swapping and cache-effects. Getting more user attention to this bug isn't going to help. How many of the users do you think are going to investigate enough to really have a qualified oppinion? Have any of you commenting in this bug so far? Sure, if you want to modify the summary/whiteboard/whatever to bring more attention to this bug go ahead. Just don't think it'll make the bug "fixed" faster. Complicated bugs like these have a tendency to just get more noisy when too many non-developers get involved, making it even less likly to get fixed due to the bug in effect getting useless.
13 years ago
Comment 65 and comment 67 are not adding value here, they are making it less likely this bug will be fixed. Helping other newcomers come to this bug, vote for it, and spam it with "me too" or similar comments does not help fix the bug -- it actually hurts. Please stop. I'll do some investigation and prototyping over the holidays. /be
After 4+ years, I think it is apparent the existence of this bugzilla entry and its comments are not having any substantive impact one way or another on the software functionality, so I think it is reasonable to expect that more votes and "me too"s are also not going to have any such effect; but, if they serve as a rallying cry for people to come to see how many others are dissatisfied with the behavior of the code and the perennial failure to improve it, I think that might help the user community by providing an impetus for change which does not call for the assent of those who have so persistently chosen not to improve the behavior of the software.
In reply to comment 70, I think you need to realize this *is not* an easy bug to fix. It's rather involved. This is clearly one of the harder bugs in bugzilla to fix. If it were easy to fix, it would have been done years ago. The fact that people want it fixed, doesn't make it fixed. The only thing that fixes it is someone stepping up and doing the job. I think that's the point timeless was trying to make. I want a billion dollars, but posting that doesn't make it a reality. **** unless you have something relevent to say regarding the patching of this bug, please refrain from comments ****
> This is clearly one of the harder bugs in bugzilla to fix. If > it were easy to fix, it would have been done years ago. I do not think the reason the misbehavior continues to exist is so much the high cost of improving things as it is the lack of perceived benefit to those who would bring about that improvement, and/or the perceived cost of failing to do so. > The fact that people want it fixed, doesn't make it fixed. The > only thing that fixes it is someone stepping up and doing the job. I think the point made here and elsewhere is that after 4+ years, there is no reason to expect anything is going to get done before the level of awareness and/or perception of the costs/benefits changes. I would posit that broader awareness of impact (and so cost/benefit) is often a key determining factor in someone "stepping up and doing the job".
Comment 70 tears it. I'm opening a new bug to track the work for this bug. Posturing can continue here, but if any of you noisemakers spams the new bug with non-technical content, I'll personally revoke your bugzilla privileges. Vent frustration over lack of this feature in the newsgroups, or better yet, do something on the technical side, or pay someone who can, to help. /be
To do this properly, I think you have to separate the JS global scope object from the "window" object; which is something I think we should do for security reasons anyway. I don't see why scripting is a big deal; if we're going back/forward to a page which has already "loaded", there is no reason to fire onload events.
Larry, you're pretty insulting. Do you honestly think that the people that developed a piece of software that was downloaded more then 10000000 times in 32 days doesn't know what features users want? What makes you think that you need to run some sort of awareness campain for the mozilla developers? You're talking about awareness of the cost/benefit of this bug. Are you aware of it? If you are, plase tell us, that'll save us (brendan in this case) the trouble of writing a whole lot of code and doing a whole lot of instrumenting. You're arguing for a bug that you have no idea what it's going to do. What if it speeds up back/forward by 10% but slowing down loading of new pages by 50% due to disk thrashing? When I filed this bug it was not mostly for speed of back/forward, that was a hoped for sideeffect. So let me spell it out again. It is *not known* if implementing this suggestion will have a positive effect on the performance of mozilla. Arguing that this bug should be implemented means arguing for something that you have no idea what it is.
(In reply to comment #65) > (In reply to comment #64) > > timeless: cut the ****, two wrongs don't make a right, etc. > > > > /be > > Does anyone think that another bug should be created for Firefox, similar to > this, but be considered a enhancement. It would say, "Improve the caching of > pages to prevent any unnecessary reloading or rerendering of pages when going > backwards and forwards to be as fast as Opera" That keeps it open and might > attract more attention from the devs, because this bug is 4 years old, sort of > confusing and too specific and probably not going to be fixed this decade. ... If that is the case, they should just mark it as "WONTFIX". I didn't know they were not fixing old bugs any longer.
(In reply to comment #71) > In reply to comment 70, I think you need to realize this *is not* an easy bug to > fix. It's rather involved. This is clearly one of the harder bugs in bugzilla > to fix. If it were easy to fix, it would have been done years ago. > > The fact that people want it fixed, doesn't make it fixed. The only thing that > fixes it is someone stepping up and doing the job. I think that's the point > timeless was trying to make. I want a billion dollars, but posting that doesn't > make it a reality. > > > > **** unless you have something relevent to say regarding the patching of this > bug, please refrain from comments **** I bet the community as a whole would benefit and in the end greatly appreciate it if the entire Mozilla team took off the next three months from all other fixes to focus on this one bug and maybe some of the memory bugs.
(In reply to comment #77) > I bet the community as a whole would benefit and in the end greatly appreciate > it if the entire Mozilla team took off the next three months from all other > fixes to focus on this one bug and maybe some of the memory bugs. It's hard to tell whether you are being sarcastic or not... I hope that you are.
(In reply to comment #77) > I bet the community as a whole would benefit and in the end greatly appreciate > it if the entire Mozilla team took off the next three months from all other > fixes to focus on this one bug and maybe some of the memory bugs. I'm afraid that you absolutly don't understand what you're talking about. You have probably no idea how does Mozilla project works nor what are it's targets. I strongly advice you spending time to learn it by looking and reading rather than writing such words. Overall - we're accepting patches so if You're such desperate - feel free to pay somebody to code this or code this by yourself. I'm talking seriously. We had previously some situations when people/companies payed somebody/a group to fix some bugs. And thats the best way You all can go, while the worst is to yawl more here.
If here is spam is allowed I dive my 5 eurocents i this sh... There is about $150k left from the Times advertising left. Could the money go for financing such a bugs like this one?
> There is about $150k left from the Times advertising left. Could the money go > for financing such a bugs like this one? Those funds were donated by individuals to a non-profit for a single purpose, and it's illegal under the laws governing that non-profit to use them for other purposes -- and the ad actually cost more than what was raised (MF made up the difference), in order to be two pages and have big enough font that donors' names show up. And yes, your comment is spam here. /be
My spam-reply needs correction: Chris Beard of MF got a great deal from the NYT and MF didn't end up having to kick in more funds (but we were willing to, if it had been the right thing). My point about non-profit law binding us from using those funds for arbitrary purposes stands. /be
*** Bug 271851 has been marked as a duplicate of this bug. ***
Note bug 288462.
*** Bug 291777 has been marked as a duplicate of this bug. ***
Fixed in bug 274784. Download Firefox 1.5 Beta 1 and try it out :) Dataloss issues (e.g. Firefox should know to pin a page in bfcache but doesn't) should be filed as separate bugs. *** This bug has been marked as a duplicate of 274784 ***