Browser History:Redirects: Difference between revisions

Jump to navigation Jump to search

Browser History:Redirects (view source)

Revision as of 21:49, 14 December 2005

298 bytes added ,  14 December 2005
Proposal details
(Added review)
(Proposal details)
Line 116: Line 116:
This redirect function would attempt to QueryInterface the global history to a new interface we define (let's call it nsIGlobalHistory3 for now). If unsuccessful, it would revert to calling the old nsIGlobalHistory2.AddURI. Otherwise, it would call nsIGlobalHistory3.AddURIFrom and give it information about the redirect and a pointer to the docshell.
This redirect function would attempt to QueryInterface the global history to a new interface we define (let's call it nsIGlobalHistory3 for now). If unsuccessful, it would revert to calling the old nsIGlobalHistory2.AddURI. Otherwise, it would call nsIGlobalHistory3.AddURIFrom and give it information about the redirect and a pointer to the docshell.


The "regular" calls to AddURI would also be changed to use the new AddURIFrom function.  
The "regular" calls to AddURI would also be changed to use the new AddURIFrom function.


The docshell will be extended to support nsIWritablePropertyBag. When the history system gets visit notifications, it can store necessary state on the docshell (probably just a 64-bit visit ID number). This way, it can associate a given page visit as coming from a specific docshell, and know which specific page visit it came from, even if the same document is open in more than one docshell.


The history system would treat these docshell pointers as opaque identifiers in a hashtable for associating some state with. This state would include the typed and bookmarked information as discussed above, as well as the visit ID of the previous page from the docshell. This way, we can tell when we get new notificaions exactly which visit was the source.
Global history would maintain queues of URLs for typed and bookmarked flags. When new URLs come through that have no referrer, it would check these queues to see if the URL had either of these flags set. This requires no changes to non-history system code, but it could be confused in some unusual cases (for examples, if the user types and and follows a bookmark in quick succession for the same URL). The side effect of getting it wrong is very minor.
 
In Docshell::Destroy, the global observer notification NS_WEBNAVIGATION_DESTROY is sent with a pointer to the docshell. The history service can observer these events and know to delete the corresponding state.


Review of changes in old code:
Review of changes in old code:
Line 127: Line 126:
* New nsIGlobalHistory3 interface defined in toolkit.
* New nsIGlobalHistory3 interface defined in toolkit.


* New virtual function in docloader.
* New virtual function OnRedirectStateChange in docloader.


* Move redirect code from OnStateChange to new function in docshell.
* Move redirect code from OnStateChange to onRedirectStateChange.


* Change docshell AddToGlobalHistory to use the new AddURIFrom if it is available.
* Change docshell AddToGlobalHistory to use the new AddURIFrom if it is available.


* Implement nsIWritablePropertyBag in the docshell
* Implement nsIWritablePropertyBag on the docshell.
BrettWilson
202

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/15149"

Navigation menu