"lockHistory" does this.

Can you give a specific example of why you think this needs to be a whole new load type? Something that can't be done today?

~Brady

On Oct 13, 2009, at 8:48 AM, tonikitoo (Antonio Gomes) wrote:

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 <aba...@webkit.org> 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)
<toniki...@gmail.com> 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
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
--Antonio Gomes
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to