Judson Valeski wrote:
> Rick Potts wrote:
>
>> I'm currently looking at the nsIWebNavigation interface... I think
>> that the following changes to the interface are necessary:
>>
>> 1. Add a 'postData' argument to LoadURI(...).
>> This will address bug #46870... 2. Rework the LOAD_FLAGS for
>> LOADURI(...).
>> See my previous posting on 'load flags' for my justifications :-)
>
>
> we had previously discussed hanging load flags, post data, referrer,
> etc, off of some sort of nsILoadInfo that could be passed into
> LoadURI(). there would be a readonly nsILoadInfo attribute hanging off
> of nsIWebNavigation. is this idea dead? I liked it because it would
> ultimately mean fewer mods to nsIWebNavigation as new attributes/flags
> cropped up, and it would also keep nsIWebNavigation clean.
No... having a separate LoadInfo object is still a possibility... I'd
be moving away from it though - because i was hoping to contain the
number of arguments required by LoadURI :-) If we can limit LoadURI to
take just 3 arguments then i don't think that we need the separate object...
>
>> 3. Add a 'readonly attribute' postData.
>> This addresses bug #40867. This patch has already been applied to
>> the branch.
>
>
> if we go this route, I'd be inclined to have the attribute be
> read/write, then do away w/ the argument to LoadURI(). it seems
> disjoint to put the post-data in one place, then pull it out another.
The reason I chose to make the 'postData' attribute read-only and have
the 'setter' implicit via LoadURI(...) was to 'simplify' the semantics
of the interface :-)
I sortof dislike the model of setting a bunch of attributes on the
object and then call a 'do-it' method like LoadURI(...). I thought that
it was simpler to say that the postData is always available (read-only)
but it can *only* be set as part of a call to LoadURI(...).
Of course, this is *exactly* what i'm proposing with the new 'referrer'
attribute :-) At first, i really wanted to make it read-only too. But
then there would be not way to prevent the referrer from being passed
along... So, i thought that it was reasonable to say that LoadURI will
use the current 'referrer' value as the 'referrer' header... I don't
know... it's a fine line to draw :-)
After looking at the rest of the current information that's stored in
the LoadInfo (ie. owner, target-window and whether the content should be
stopped at the beginning of the load) i hope that we can avoid exposing
these pieces of information at the nsIWebNavigation level...
>
>> 5. Add a 'flags' argument to Stop() to allow control over what is
>> stopped...
>> Currently, there is no way via public interfaces to stop content,
>> the network, or both...
>> flag states:
>> STOP_CONTENT - call nsIContentViewer::Stop().
>> STOP_NETWORK - stop refresh timers and call nsIURILoader::Stop().
>> This is the same as
>> nsIDocShell:StopLoad()
>> STOP_ALL - STOP_CONTENT | STOP_NETWORK
>
>
> great idea. should STOP_CONTENT be broken out into STOP_JS and
> STOP_CONTENT (animated images for example). does STOP_CONTENT imply
> stop plugins (I assume no)?
The current semantics of 'STOP_CONENT' are to call
nsIContentViewer->Stop(). This will cause plugins to be stopped.
You're probably right that STOP_CONTENT should be refined to allow
animated images to be stopped without affecting JS/plugins...
-- rick
