[webkit-dev] Adding a "load type" that specifically does not touch session and global history

[tonikitoo (Antonio Gomes)]

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 <abarth at 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)
> <tonikitoo at 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>



-- 
--Antonio Gomes