Hi Adam, although the "lockHistory" naming suggests it to be related to what I pointed ou, they are currently not ..
ps: i totally also agree they could work together here. >From what i could understand (and for the test cases i faced for this missing load type in the past), in current FrameLoader state there are some other more related methods to this "load w/o touching history" thing, including ::shouldReloadToHandleUnreachableURL and ::shouldTreatURLAsSameAsCurrent , among others. Generally speaking, If SubstitutionData is valid (see FrameLoader::load overloaded method), but it holds invalid failingURL, session and global history are not changed, but it is *only* handled in HistoryController::updateForStandardLoad(). My initial suggestion would to re-think the above method, considering this possibly new load type. On Tue, Oct 13, 2009 at 11:27 AM, Adam Barth <[email protected]> wrote: > There's a notion of "lockHistory" in FrameLoader. Is that related to > what you mean? I haven't studied load type yet. > > Adam > > > On Tue, Oct 13, 2009 at 8:22 AM, tonikitoo (Antonio Gomes) > <[email protected]> wrote: >> Adam, something else that imho must be considered ( while refactoring >> the state machine ) is adding a "load type" that specifically does not >> touch session and global history, and avoid "abusing" some of the >> existent load types like below: >> >> <abuse> >> // FIXME: This seems like a dangerous overloading of the meaning >> of "FrameLoadTypeReload" ... >> // shouldn't a more explicit type of reload be defined, that means roughly >> // "load without affecting history" ? >> if (shouldReloadToHandleUnreachableURL(newDocumentLoader)) { >> ASSERT(type == FrameLoadTypeStandard); >> type = FrameLoadTypeReload; >> } >> </abuse> >> >> >> great effort so far , btw >> >> -- >> --Antonio Gomes >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > -- --Antonio Gomes _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
